[cap-talk] [e-lang] File API taming
Stiegler, Marc D
marc.d.stiegler at hp.com
Tue Mar 24 14:11:19 EDT 2009
Your comments make me realize that I understand even less about Tahoe than I thought I did, and I need to bring up your service on my box to learn enough to not sound foolish talking about it.
But that is not going to happen today or tomorrow. So let me lay out my meta-philosophy and then pursue my ignorance to its final grim conclusion.
The meta-philosophy is simply this: human beings have terrible trouble communicating successfully with each other (witness more than one of these captalk threads :-). Any time a program gets the opportunity to latch on to some information that could help the humans coordinate their actions and understand their relationships, the computer should make a ferocious attempt to present that information in contexts where it might help. The program should be deprived of such helpful knowledge only if the benefits to purposes other than human coordination are outstanding. Hence, I favor, by default, giving the program receiving a file the path information that may help in coordination. I don't even care if it is pristine or elegant. I would just like to see the humans succeed a little more often with a little less pain.
If Tahoe really is purely a hypertext system without a file system, perhaps there isn't any more information aside from a filename available. I had thought that Tahoe had things that approximated directories, composable into directory structures, so you could put a file in a directory, and put another directory in a directory. If you can put a single file into multiple directories, that would still befine, a directory could (should? must?) have a facet on the file that is, in the context of that directory, the file's name. So if you reach a file through a particular navigation path through directories, you have a contextual path associated with that file and its contextual filename derived from that directory structure. This could again be useful information for the humans trying to coordinate which file named "brochure.txt" they are trying to work on together. If the filename is wired to the file, such that there is only one file object (no facets), reachable from many directories, then the useful context information might be, the list of names of directories that are backlinked from the file. So suppose you have a folder for your colgate marketing campaign and another folder for your pepsodent marketing campaign, and each of them has a link to a file named brochure.txt. It could be really useful for coordination for the 2 humans to say to each other, right now we are going to work with the brochure.txt that is backlinked to the colgate directory.
> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of zooko
> Sent: Monday, March 23, 2009 2:21 PM
> To: General discussions concerning capability systems.
> Cc: Discussion of E and other capability languages
> Subject: Re: [cap-talk] [e-lang] File API taming
> On Mar 23, 2009, at 11:17 AM, Stiegler, Marc D wrote:
> > Do programmers use the file api? No, of course not, it is too
> > complicated. What they do is, every app stores its "files"
> in its own
> > private space in a custom-built directory system (like
> Google Docs and
> > Sheets) so that the app can handle its files and its names easily.
> > This blasts all hope of interoperability with other apps to
> > smithereens, but that is a secondary problem compared to making the
> > app able to quickly and easily fulfill its own purposes.
> Dear MarcS:
> I appreciate your pragmatic, user-oriented contributions to
> the discussion.
> I think you are right that programmers often store file
> objects in a custom namespace of their own device. But I
> don't think that blasts all hope of interoperability, because
> those same programmers know that to share a file with some
> other object they need to pass the reference ot the file
> itself, not just its name within their own custom namespace.
> They may want to pass other additional metadata, such as the
> name of the file within their custom namespace or within some
> other context that was supplied to them when they received
> the file in the first place. They could also pass, instead
> of a capability to a file itself, a capability to some
> directory, plus a path starting from that directory and
> leading to the file.
> In deployment of Tahoe (which I think is probably
> representative of any crypto-capability file storage scheme),
> I observed several instances of this sort of behavior.
> One thing that I haven't been able to reconcile so far is how
> your suggestion of providing "the pathname" could even
> *possibly* be implemented on a crypto-cap system like Tahoe
> (or even a Unix filesystem with its symlinks, hardlinks, and
> mount points). There
> *isn't* one canonical path leading to a given file.
> Different people may have differently organized directories
> pointing to the same files. Think of it as a hypertext
> system with capability hyperlinks instead of as a local
> filesystem and tell me what you think.
> cap-talk mailing list
> cap-talk at mail.eros-os.org
More information about the cap-talk