[tahoe-dev] encoding issues in Tahoe v1.5 in June (was: File naming on POSIX and Windows clients [was: PEP 383 update: ...])

[Zooko Wilcox-O'Hearn]

(Cc: a bunch of folks who have contributed code and/or ideas to the  
encoding issues in Tahoe-LAFS; and thank you for your contributions!)

Folks:

Since some of you might not be reading the tahoe-dev list thoroughly,  
I wanted to draw this note to your attention:

http://allmydata.org/pipermail/tahoe-dev/2009-May/001738.html

It says I'm prioritizing ECDSA, so I'm not planning to spend my time  
implementing better encoding before the v1.5 release in June.  I do  
want to understand what the possibilities are in order to be careful  
not to allow behavior in v1.5 that would make it *harder* to improve  
encoding in the release after that.  Also, if possible, to put  
something in v1.5 which will make it easier to improve behavior in  
future releases.  For example, I'm pretty sure that copying the  
original bytes from a byte-oriented filesystem into the Tahoe  
metadata, but *not* using those bytes for anything, can't hurt  
(beyond expanding the size of directory entries) and might help.

So my plan is to 1.  understand the various proposals, 2.  re-read  
François's patches to ticket #534 and see if they are compatible with  
proposals that we might want in the future, 3. (if I have finished  
the ECDSA work) make sure François's patches are thoroughly covered  
by tests and commit them to trunk, 4. implement copying the bytes  
into the metadata or other such changes as can't hurt and might help.

If anyone else wants to contribute to this project before I've  
finished the ECDSA work, that would be cool.  Do the steps above in  
order and write to tahoe-dev with what you learn!

Thanks!

Regards,

Zooko

tickets mentioned in this e-mail:
http://allmydata.org/trac/tahoe/ticket/534 # "tahoe cp" command  
encoding issue
---
store your data: $10/month -- http://allmydata.com/?tracking=zsig
I am available for work -- http://zooko.com/résumé.html