[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