[tahoe-dev] webapi updates

zooko zooko at zooko.com
Tue Aug 14 10:46:30 PDT 2007


> But for this issue in particular, I'd also like to keep the FURL as an
> opaque string (with certain promises, like no spaces or the like),
> rather than defining our dirnode URIs in a way that's highly dependent
> upon the FURL syntax. If we decided tomorrow that our dirnode URIs  
> could
> use an HTTP reference to point at the contents (say, is someone were
> using an apache server to provide read-only access to some large  
> static
> directory structure, or something), then it'd be nice if the only  
> thing
> that changed was the code that interprets the portion of the URI that
> tells it how to get to the dirnode server.

So one option is for the user of foolscap (i.e., tahoe) to escape the  
slashes in order to pass them through an HTTP request back to itself  
(tahoe) so that it can then pass the furl portion of the dirnode to  
foolscap.

That's what we're currently doing.

You mention another option: have tahoe parse the components of the  
furl and pack them tightly and without troublesome chars, put it in a  
dirnode, pass the dirnode through HTTP to tahoe, and then tahoe re- 
encodes it to foolscap's furl format to give it to foolscap.

What about a third option:

Foolscap provides a "tight, no-special chars" encoding of furls.   
This encoding of furls has no redundancy, which means it is not  
recognizable as a furl without context.  Tahoe provides that context  
(by the way that tahoe packs it into the dirnode), and passes the  
dirnode through HTTP to tahoe, which extracts the furl (using the  
tahoe-specific context to know what part of the dirnode is the furl),  
and passes the "tight" furl to foolscap.

Regards,

Zooko



More information about the tahoe-dev mailing list