[tahoe-dev] help! how do I manage dependencies on JavaScript code?

[Zooko O'Whielacronx]

On Fri, Sep 3, 2010 at 10:24 AM, Chris Palmer <chris at noncombatant.org> wrote:
> Zooko O'Whielacronx writes:
>
>> Can you be more specific?
>
> The WUI, SFTP, this visualization thing. Whatever causes the standalone
> download package to still not build on FreeBSD. (I stopped trying.)

Can you remember what the "Whatever" was? I vaguely recall from
chatting with you on IRC that it was
https://bugs.launchpad.net/pycrypto/+bug/518852 , which for what it is
worth has been fixed in the recent PyCrypto v2.3 release. Also FWIW
David-Sarah is working on contributing  patch to Twisted (which patch
I mentioned previously) that would eventually eliminate Tahoe-LAFS's
dependency on PyCrypto.


> So, so much could be unbundled. It's a filesystem. NFS has no PyCrypto
> dependency, Samba has no darcs dependency...

I can't think of a useful way to respond to this part, except to
mention that Tahoe-LAFS doesn't depend on darcs.


> And you're making my case. The SFTP code should not exist. Tahoe-LAFS should
> be a FUSE filesystem. Once you have that, you get everything else for free,
> because all programs in the world ever know how to use filesystems.

This is proposing a radically different strategy which we could have
embarked upon when we started designing Tahoe-LAFS a little over four
years ago. It would not have been an unalloyed (Pareto) win. It would
have had certain major advantages to be sure, but it would also have
had significant added costs. In particular I don't think we would have
had a working version of Tahoe-LAFS v1.0 two years ago if we had taken
that route, and so today it would probably still be just me and Brian
stubbornly coding on it instead of the larger group of users and
contributors that we have now. ;-)

I would be happy to see a more filesystem-oriented and a more unixy
"minimal composable pieces" approach. I know you, Chris, have been
working one in your copious spare time --
http://wieldysoftware.com/octavia/index.html -- and I've even
contributed a bit of documentation-review and design-review to
Octavia. I would be willing to contribute more to Octavia in *my*
copious spare time...

The Tahoe-LAFS hackers have a shared vision of someday factoring out
the pieces and documenting and specifying them clearly enough to
facilitate re-implementation, standardization, and composition. See a
few related links below. As usual the limiting factor seems to be the
amount of time being contributed by volunteers. You could help! #865,
for example, would be something that you would be very good at, the
fact that you aren't already familiar with the details would help you
write better docs, and studying the Tahoe-LAFS crypto details might
provide ideas (positively or negatively) for your Octavia design.

http://tahoe-lafs.org/trac/tahoe-lafs/ticket/510# use plain HTTP for
storage server protocol
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/865# Document current
crypto and encoding in detail
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/869# Allow Tahoe
filesystem to be run over a different key-value-store / DHT
implementation

http://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/specifications/outline.txt

Regards,

Zooko