[tahoe-dev] change of priorities for v1.5: ECDSA

[Francois Deppierraz]

Hi Zooko,

Zooko Wilcox-O'Hearn wrote:

> By the way, the encoding issues remain so deeply perplexing, even  
> after such intense study, that I'm increasingly interested in  
> something that François proposed a while back: implement the easy  
> parts first!  In particular, I would like to carefully review the  
> extensive alternatives proposed so far with an eye to "What can we do  
> in v1.5 which will at least not preclude us from implementing one of  
> these improvements in v1.6, and especially which will not obligate us  
> to maintain compatibility with a design that we may later regret.".

Indeed, those issues are way more complex than what I was thinking when
I first reported bug #534 ;)

> For example, putting the flat binary contents of filenames into the  
> Tahoe metadata when copying from local system into Tahoe doesn't  
> hurt.  *Using* those binary filenames for anything when copying from  
> Tahoe into local system might.  ;-)  More on that later.

Well, if I understand correctly what Brian said in [1], you cannot put
binary content in metadata without modifying the webapi.

Brian Warner wrote:

> One limitation to keep in mind is that JSON cannot represent arbitrary  
> binary data without application-visible encoding, and that both the  
> webapi GET $dircap?t=json and the dirnode-format metadata dict use  
> JSON. So any "store the original bytes and let the reader sort it out"  
> approach must e.g. base32-encode those bytes on the way in and base32- 
> decode them on the way out, in the CLI tool on the user side of the  
> HTTP connection.

My current proposal, as implemented by [2] is simply to allow
*correctly* encoded filenames to be stored in Tahoe using the CLI. It
does not even try to do any magic if decoding of a filename according to
sys.getfilesystemencoding() fails. Instead, it asks the user to fix his
filesystem.

I don't see any reason for these changes to break compatibility.

I agree that handling incorrectly encoded filenames would be nice to
have in the future, but let's first focus on getting *correctly* encoded
filenames working in Tahoe 1.5.

If people interested in this issue could test this patch, especially
under Windows and MacOS X, that would be pretty helpful !

François

[1] http://www.mail-archive.com/tahoe-dev@allmydata.org/msg00497.html
[2]
http://allmydata.org/trac/tahoe/attachment/ticket/534/tahoe-534-bundle.dpatch