(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 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
