[tahoe-dev] capability researchers on file/directory APIs

[zooko]

(Carbon-copying cap-talk.)

Dear people of tahoe-dev:

There is an active discussion on the e-lang [1] and/or cap-talk [2]  
mailing lists about file/directory APIs.  It is very thought- 
provoking and (unlike a lot of the traffic on those mailing lists) it  
includes specific proposals for actual APIs.

Here are a few pointers into the discussion, but I'm not sure if I've  
really understood it all so if you are interested in this you should  
probably read the complete thread yourself:

Ihab Awad asks about the E filesystem taming API and proposes a more  
object-ish one for his JavaScript project: [3].

I reply saying that Ihab's proposed API is a lot like Tahoe's API,  
and that the Tahoe API seems to be usable but not without problems: [4]

Marcus Brinkmann replies to my comment citing an old paper by Rob  
Pike on "getting .. right": [5]

Marc Stiegler says that when writing UI code he frequently wants to  
get the pathname/filename for a given file object:  [6].

David-Sarah Hopwood responds to MarcS's note with, in effect: but a  
given file object doesn't always have just one pathname/filename --  
it might have zero or several: [7].  (David-Sarah's point is not so  
true, I think, for Windows filesystems, but it is true for Unix  
filesystems, and eminently true for decentralized cryptographic  
filesystems, where requiring a given file object to have at most one  
pathname/filename would be tantamount to requiring that everyone in  
the universe refrain from pointing at that object using a hyperlink  
with a different anchor text.)

Kevin Reid responds to MarcS's note with a proposal for pet-name-ish/ 
provenance-ish naming scheme: [8].

Rob Meijer (author of MinorFS [9. 10]) replies to Kevin's message  
saying, if I understand him correctly, that if you have a reference  
to a directory, you don't get much added authority by also knowing  
which local name within that directory denotes the file: [11].

Kevin Reid responds to a different message suggesting another  
technique, which I think is to pass around a reference to a directory  
plus the local name within that directory instead of passing around a  
reference to a bare file, nor a path name from some other further- 
away directory: [12].  Note, I *think* that this is the technique  
that I described using in Tahoe in my message.

Marc Stiegler tries to elucidate two tangled threads in the  
discussion and tie it back together with his GUI work, his SCoopFS  
[13] work, and Tahoe: [14].

Phewf!

If you're interested in improving Tahoe's filesystem API, or at least  
in writing up a document explaining how the current one can't be  
improved upon (;-)) then please dive in!

Regards,

Zooko

[1] http://www.eros-os.org/mailman/listinfo/e-lang
[2] http://www.eros-os.org/mailman/listinfo/cap-talk
[3] http://www.eros-os.org/pipermail/e-lang/2009-March/013031.html
[4] http://www.eros-os.org/pipermail/cap-talk/2009-March/012398.html
[5] http://www.eros-os.org/pipermail/cap-talk/2009-March/012399.html
[6] http://www.eros-os.org/pipermail/e-lang/2009-March/013041.html
[7] http://www.eros-os.org/pipermail/e-lang/2009-March/013045.html
[8] http://www.eros-os.org/pipermail/e-lang/2009-March/013055.html
[9] http://polacanthus.net/
[10] http://www.linuxjournal.com/article/10199
[11] http://www.eros-os.org/pipermail/cap-talk/2009-March/012405.html
[12] http://www.eros-os.org/pipermail/e-lang/2009-March/013047.html
[13] http://www.hpl.hp.com/techreports/2009/HPL-2009-53.html
[14] http://www.eros-os.org/pipermail/e-lang/2009-March/013054.html