[tahoe-dev] thoughts about v0.6
zooko
ZOOKO at zooko.com
Tue Aug 21 12:47:54 PDT 2007
Folks:
v0.5 is out, and it is very cool because it has a working web API and
command-line interface.
I'm hoping that some people will start using v0.5 for friendnet
filesharing, friendnet backup, or for hacking experiments using the
web API to program the tahoe node.
Now v0.6: one thing that I want is for the release cycle to be
shorter. v0.5 took 51 days, which was way too long. We currently
have a target date of 2007-09-20 for v0.6.
What should go into v0.6? Well, there are a lot of things --
probably not all of them will get done by that date. Here they are
in no particular order. By the way, you can see a single web page
listing all of these tickets here:
http://allmydata.org/trac/tahoe/query?
status=new&status=assigned&status=reopened&groupdesc=1&group=component&m
ilestone=0.6.0&order=priority
* API improvements -- tickets #98, #118, #102
Basically, make the API safe against XSRF attacks and perhaps also
make it cleaner/prettier/better to program.
* lease expiration / deletion / filechecking / quotas -- ticket #119
Invent an active process for monitoring and repairing the
filesystem over time.
* command-line improvements -- tickets #104, #105, #107, #110,
#112, #113, #114
Extend the command-line to support more of the unix tradition.
The most important of these is probably "recursive get and
put" (ticket #104).
* data reliability -- tickets #90, #86, #16
#90 is preparing for future schema evolution, #86 is a double-
check for correctness (if data corruption happens, this should show
whether the reason it happened was that the secret key was wrong)
#16 is about making the peer selection algorithm distribute data
shares evenly in order to avoid the chance that one node could have
many shares on it. This also makes the peer selection algorithm less
scalable in some technical way or other that I currently don't
remember, but Tahoe v0.6 can't scale beyond a couple of hundred nodes
anyway due to other limitations.
* packaging/build system/porting -- tickets #82, #42, #10, #47,
#93, #27
Basically, make it so that we re-use third-party libraries as
independent packages instead of including their source code in the
tahoe source tree, use setuptools to package and publish tahoe, and
make it so that you don't have to run "make" in between editing
Python source code and running it in place.
* operational -- ticket #13 "collect stats on download counts,
testnet utilization"
Regards,
Zooko
tickets mentioned in this message:
http://allmydata.org/trac/tahoe/ticket/10
http://allmydata.org/trac/tahoe/ticket/13
http://allmydata.org/trac/tahoe/ticket/16
http://allmydata.org/trac/tahoe/ticket/27
http://allmydata.org/trac/tahoe/ticket/42
http://allmydata.org/trac/tahoe/ticket/47
http://allmydata.org/trac/tahoe/ticket/82
http://allmydata.org/trac/tahoe/ticket/86
http://allmydata.org/trac/tahoe/ticket/90
http://allmydata.org/trac/tahoe/ticket/93
http://allmydata.org/trac/tahoe/ticket/98
http://allmydata.org/trac/tahoe/ticket/102
http://allmydata.org/trac/tahoe/ticket/104
http://allmydata.org/trac/tahoe/ticket/105
http://allmydata.org/trac/tahoe/ticket/107
http://allmydata.org/trac/tahoe/ticket/110
http://allmydata.org/trac/tahoe/ticket/112
http://allmydata.org/trac/tahoe/ticket/113
http://allmydata.org/trac/tahoe/ticket/114
http://allmydata.org/trac/tahoe/ticket/118
http://allmydata.org/trac/tahoe/ticket/119
More information about the tahoe-dev
mailing list