[tahoe-dev] what to improve in Tahoe-LAFS v1.7

Zooko O'Whielacronx zookog at gmail.com
Sat Feb 27 06:43:06 UTC 2010


There is a panoply of possible improvements to Tahoe-LAFS, and we need
to decide which ones will go into Tahoe-LAFS v1.7. Let's plan to
release Tahoe-LAFS v1.7.0 on May 13, 2010. (That's about three months
since v1.6.0 was released, maintaining our goal of a new major release
every quarter.) This isn't enough time to do everything we want—we'll
probably finish only a subset of the following list of potential

As always, you can exert a moderate amount of influence over which
ones get done by telling us in detail which ones are important to your
use cases. You can exert a *great* amount of influence over which ones
get done by contributing tests, implementations, docs, and patch

Also, you might be able to exert influence over what gets done by
offering bounties to whoever does it! Ed Pimentl and Jack Lloyd have
launched this experiment: [1], [2]. I love the fact that they are
contributing in that way, although I don't yet know how it is going to
work out. For example, I don't understand exactly what someone would
have to do in order to claim Ed's bounty. If the bounties end up being
claimed by "the tahoe-lafs core team" working together, then we'll add
it to our pool of donation money with which to defray server expenses
and thank-you gifts.

Okay, here is a list of potential improvements grouped into categories:

1. "almost there"

These are things that we've already mostly implemented. Also, they are
awesome! :-)

 a. servers of happiness (#778)
 b. Brian's New Downloader (#287, #288, #448, #798, #800, 809)

2. "by popular demand"

This is an important category; it is never a good idea to put off
repeated requests from users.

 a. SFTP and FTP:
 b. unicode and i18n:
 c. let users specify which servers receive which shares: #467

3. "forward-compatibility"

We have an excellent tradition of maintaining compatibility while
improving the system. To keep this up requires a continual investment
in forward-compatibility. The earlier we add these features the more
it helps us:

 a. LAFS 301 Moved Permanently (#958)
 b. handle filenames which are illegal on some systems (#731)
 c. use POST, not PUT, to create a new immutable file in the WAPI
 d. rename "uri" to "cap" in the WAPI
 e. Other tickets tagged with "forward-compatibility":

4. "unfinished business"

 a. more tests for immutable directories (#972)
 b. user interface for immutable directories (#835, #904)
 c. nicer semantics for mkdir-immutable (#903, #920)
 d. FUSE dies if it looks at an immutable directory (#894)

Okay! That doesn't look so hard. Maybe we can get most of these done
for the v1.7 release! Let's go for it! :-)

Please let us know which improvements are most pressing for you.
Especially if you are willing to contribute time and/or money to make
it happen!



[1] http://allmydata.org/pipermail/tahoe-dev/2010-February/003802.html
[2] http://allmydata.org/pipermail/tahoe-dev/2010-February/003807.html

http://allmydata.org/trac/tahoe-lafs/ticket/287# download: tolerate
lost or missing servers
http://allmydata.org/trac/tahoe-lafs/ticket/288# resumption of
interrupted downloads
http://allmydata.org/trac/tahoe-lafs/ticket/448# download: only speak
to minimal number of peers
http://allmydata.org/trac/tahoe-lafs/ticket/467# change peer-selection
to allow introducerless explicit serverlist, alternative backends
http://allmydata.org/trac/tahoe-lafs/ticket/731# handle filenames
which are illegal on some systems
http://allmydata.org/trac/tahoe-lafs/ticket/778# "shares of happiness"
is the wrong measure; "servers of happiness" is better
http://allmydata.org/trac/tahoe-lafs/ticket/798# improve random-access
download to retrieve/decrypt less data
http://allmydata.org/trac/tahoe-lafs/ticket/800# improve alacrity by
downloading only the part of the Merkle Tree that you need
http://allmydata.org/trac/tahoe-lafs/ticket/809# Measure how segment
size affects upload/download speed.
http://allmydata.org/trac/tahoe-lafs/ticket/835# "tahoe cp -r
--mutable": make mutable copy of immutable directories, vice versa
http://allmydata.org/trac/tahoe-lafs/ticket/894# blackmatch fuse
doesn't know what to think about immutable directories
http://allmydata.org/trac/tahoe-lafs/ticket/903# webapi
t=mkdir-with-children and mkdir-immutable: behavior when directory
already exists?
http://allmydata.org/trac/tahoe-lafs/ticket/904# tahoe ls -l: show
"i"/"m" instead of useless "x"
http://allmydata.org/trac/tahoe-lafs/ticket/920# mkdir-immutable
probably shouldn't implicitly create (mutable) intermediate
http://allmydata.org/trac/tahoe-lafs/ticket/958# LAFS 301 Moved Permanently
http://allmydata.org/trac/tahoe-lafs/ticket/972# More tests needed for
immutable directories

More information about the tahoe-dev mailing list