[cap-talk] capability researchers on file/directory APIs
zooko at zooko.com
Mon Mar 23 15:10:30 EDT 2009
Dear people of tahoe-dev:
There is an active discussion on the e-lang  and/or cap-talk 
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
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: 
Marcus Brinkmann replies to my comment citing an old paper by Rob
Pike on "getting .. right": 
Marc Stiegler says that when writing UI code he frequently wants to
get the pathname/filename for a given file object: .
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: . (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: .
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: .
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: . 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
 work, and Tahoe: .
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!
More information about the cap-talk