[e-lang] [cap-talk] File API taming

[ihab.awad at gmail.com]

[ Responding to the last post, but really to the entire thread. ]

Thank you all for this wonderfully erudite discussion. I spent quite a while
just now reading over the entire thread. I'll summarize the things I got out
of it --

We have come to treat file "names" as intrinsic properties of the file
"nodes", while in fact they are properties of the arcs from directories.
Thus really, I would like my filesystem to tell me that some given file is
called --

  "Pepsodent Advertising Revenue Report"

and is known by the name --

  /home/ihab/docs/pepso/ads.doc

All modern document editors have a "Title" field. How many of us fill it out
completely as soon as we open a document? Show of hands? ;) ... Right. We
rely on the path to disambiguate. As long as we continue to do this, I have
to agree at least to some extent with MarcS that we have no recourse but to
treat the path as -- if not essential information -- then at least
*helpful*.

At this point, I need to remind myself that I am talking about taming a
traditional filesystem. If we were building a new persistent object system
from scratch, then Kevin Reid's remarks about building a "history" tracker
to keep track of objects and annotate them with context would apply, and I
think we should throw out all this mess we have now and start over.

MarcS mentioned Google Docs and Spreadsheets as an example of something that
builds its own naming scheme, more or less. Actually, Google Docs indexes
the "Title" of the document; its internal identifiers are machine generated
and cap-like. For example, in my Google Docs, I have two documents titled
"Foo" right now:

  http://docs.google.com/Doc?id=dfgxb7gk_64g2czqgg6
  http://docs.google.com/Doc?id=dfgxb7gk_639z5xfsfh

They both show up by their title, "Foo", in the UI. I don't know what the
product managers of Google Docs would say about this, but if I were to
channel them, I'd say, "This is Google -- search!"

MarcS mentioned that it is unlikely for files to contain secret information.
Yes, for the common case that is true, but. There are many of file names in
proprietary server apps that would be disastrous (or at least embarrassing
:) if leaked.

David-Sarah's point about <DirectoryEntry> vs. <File> is a good one. An
equivalent suggestion is from MarcS, regarding the ability to "makeOpaque()"
a file, thus "orphaning" its path in the directory hierarchy; essentially, a
"chroot()". Except David-Sarah's scheme is _prix fixe_ while MarcS's is _a
la carte_.

In the setting in which this problem is most urgent, we wish to endow a
JavaScript module sandbox, per the Securable Modules proposal of ServerJS:

  https://wiki.mozilla.org/ServerJS/Modules/SecurableModules

with some reference to *something*. Having read over this thread, I think a
pragmatic solution would be if:

* Files provide no "getParent()";

* Files provide a "getPath()" up to the closest makeOpaque()-ed directory;
and

* Each sandbox gets a reference to a (usually -- but not always --
makeOpaque()-ed) reference to a directory that serves as its "chroot()-ed
jail".

Does that sound reasonable?

Ihab

-- 
Ihab A.B. Awad, Palo Alto, CA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/e-lang/attachments/20090409/7d31a50a/attachment.html