[e-lang] File API taming

[Marc Stiegler]

It feels to me like we have 2 similar but independent questions here
that are being munged together. One is, should the names for files be
rooted in the OS file system, or should they be directory-local? The
other is, what should the api-default policy be for revealing that
name to objects receiving a reference to the file?

Directory-local names for files, as described by Zooko, are more or
less fine by me (I say more or less because I have no feel for how
pleasant they would be in practice; I take his word for it that it
works ok). But I believe that enabling the recipient of a file object
reference to easily grab this human-readable identifier is crucial to
enable diverse interactions between the authority recipient, the file,
the human, and the human's other human and computational partners.

Let us consider the following question: I launch an app, and the app
wants to ask me for a file to process. The app asks its powerbox to
negotiate with the user for a file on its behalf. So far, so good.
But:

If the powerbox uses a file dialog to interact with the user, what are
the folder roots that the powerbox should offer as the top of the
world in which the user will navigate to select this file? If the app
needs to know the name/path (where "path" here is defined as, the
sequence of folders one navigates through from the local relative root
to get to it) in order to tell the human which file it is using, or to
see the file extension so the app can decide how to handle it (jpeg or
mpeg, for example, for a multimedia viewer), how does the app acquire
this information? Note that granting the app a reference to the parent
directory just to get the file name is a crazy POLA violation.

If the powerbox uses a drag/drop operation to select the file for the
app, there is not a problem with picking a set of roots for the
navigation, but there is a fascinating problem with ascertaining which
directory is the local directory from which the name of the file
should be extracted. If even the powerbox does not know a human
meaningful name, what chance does the app have?

I find myself drawn to an approach that is akin to the linux "mount"
strategy, wherein the "full path" in one user's context is the path to
the granted-reference's root + the path from that root (in the
sender's context) down to the actual file. So this is not a global
absolute path in any sense, but it is the concatenation of the user's
petname for the root with the sender's petname for the selected file.
On the question that I consider most critical -- does the object
receiving a file reference have a getPath/getFile method by default or
not -- I still strongly favor enabling these methods by default. If
they are not enabled by default, quick and dirty programmers shall
surely make the user pay the freight in unusability ("yeah, well, I
suppose I should show the user the name of the file he is working
with, but man, that would be hard, and we had a deadline... next time
we'll avoid this ocap stuff and just do normal files").

In the presence of services like Tahoe (which has forced me to rethink
my old thinking about these matters, (I never thought about Tahoe in
the days of writing CapDesk), I propose that  files do  indeed need a
method such as makeOpaque, for which there is a special power to get
the OS-filepath name. Then the Tahoe service, when creating a new
directory tree for user Alice, hands Alice an opaque facet on the
folder (since its location in the Tahoe world is quite irrelevant to
her). Alice can communicate with the Tahoe people about problems with
a file by sending them a reference to the file, upon which they use
their special power to figure out where in the Tahoe context that file
resides. When Alice creates a new file in that tree, she gives it a
name, and inside her own system, that file's path is the composition
of the root's path in her local context + the path from the opaque
root to the file. This means that files created inside an opaque facet
are actually named again, i.e., the opaqueness is not by default
transitive (or the software on Alice's desktop always jumps through
the hoop to makeNamed off the opaque reference).

Now, when Alice shares a subfolder with Bob, she could have her choice
of sending a named or an opaque reference. Because Alice herself is
always working with named references to the file, the simplest
behavior for Alice is to send the named reference, which is to say,
she would be sending a file reference that has a path that runs all
the way up to the lowest  opaque reference (typically the opaque root
she received from Tahoe, or the actual volume root on her own system
if it is a local file rather than a Tahoe file). This would have no
impact on the normal display behavior for Bob: Bob's software would
still display a path that uses his local context down to where he
stored the reference on his machine, followed by the series of folder
names needed to navigate from that point to the file -- i.e., by
default he would not see Alice's parent names in his folder path even
though he had the authority to see them. But he would be able to do a
getProperties on the file that would show that information. This
default behavior would reveal path information to Bob that one might
argue is inappropriate, but it would be valuable for Alice and Bob
when trying to coordinate and understanding of which file of Alice's
Bob is referring to if, for example, they are working on several files
named proposal.txt at the same time.

Was this too complicated to understand? Truly, it is a lot of
complication for the minor purpose of supporting communication with
and between human beings -- but wait! perhaps making it easy for the
humans is pretty important after all, and worth some complication :-)

Amusingly, have gone through a great deal of effort to figure this out
starting from the Tahoe context, now that I am done writing it down, I
am amused that it is quite similar to what I was already planning to
do for shared folders in SCoopFS  :-)

--marcs