[tahoe-dev] Tahoe-LAFS Users Group Summary

Zooko O'Whielacronx zookog at gmail.com
Wed May 15 19:08:58 UTC 2013


Thank you for the notes about the brainstorming of future Tahoe ideas, Tony!

This is the one that most caught my attention at the Users Group Meeting:

>> - Replace Foolscap with a simplified Tahoe-specific wire protocol
...

>   In order for tahoe to grow up and be a first-classprotocol, have a written protocol spec that is independent of any language, and at least two indepdendent interoperable implementations, not in the same lanaguage.


Greg: yeah! So, at the Users Group Meeting, this topic came up, and
the conversation, involving Drew Perttula, Brian Warner, Kenton Varda
and others led to some potentially useful paths forward!

See, I've long wanted this (ticket #510, opened 2008-09-08), and it
has seemed like a big leap. We've never gotten up the gumption to
launch on the project of redefining all the protocols in a
lower-level, programming-language-neutral format (instead of
Foolscap), then implementing them all in the new format, then
supporting both the old and new formats for a while so that people can
gracefully upgrade.

But, at Pycon Brian and I talked about this, and then at the Users
Group Meeting we talked about it again with Drew Perttula and others,
and it started to seem like there is a feasible "baby step" approach
to this! The idea was that the read (download) behavior can be
implemented more easily than the write (upload) behavior, and a
read-only pure-Javascript LAFS client would be a very interesting and
useful thing. The other, complementary idea is to define a new
download protocol in terms of a single string or two which is passed
through foolscap. So, we don't have to go to the effort and disruption
of implementing HTTP transport at the *same time* as the effort and
disruption of defining a simpler, language-neutral download protocol.

This is very interesting!

Regards,

Zooko

https://tahoe-lafs.org/trac/tahoe-lafs/ticket/510# use plain HTTP for
storage server protocol



More information about the tahoe-dev mailing list