On Fri, Sep 3, 2010 at 10:24 AM, Chris Palmer <[email protected]> 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 _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
