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