[e-lang] File API taming

[Marc Stiegler]

Dean Tribble and I have a long-running low-key but adamant
disagreement about making the file objects have opaque paths, versus
supporting a method like file.getPath(). I use getPath() in E so
frequently, I cannot even characterize the circumstances under which I
do it. Well, I can characterize one circumstance pretty well. I write
lots of user interface code, and the path/name is the identifier used
to communicate with the human being. So for example, the CapEdit app
on CapDesk wants to know the name of the file so it can display that
name in the title bar. Handling this as a special case, where the app
makes a special call to the CapDesk powerbox saying "display the path
of this file", and the powerbox has a special rights-amplification
mechanism, which it uses to display the path in a rigid format and
location, that is kept opaque from the application, has so many
egregious problems, I leave the detailing of the problems as an
exercise for the reader.

Basically, the path is so useful, that if we used a rights-amp system
where we handed an explicit name-extracting authority to those objects
that need it, in the apps I have written that object would have to be
passed around so much it would be a serious irritation and obstacle to
adoption.

If the purists really feel an opaque file object must be supplied as
part of the api, I would recommend that the default File object have
both a getPath() method and a getOpaque() method, where the opaque
method returns a file object for which there is no getPath() method. I
consider this unnecessary, myself. Note that, if this is not supplied
as part of the api, it is easy for the programmer who cares about it
to create his own makeOpaque(file) function that would supply this
attenuated authority.

Please remember, the goal of taming is not actually to implement POLA:
only the specific programmer can know what POLA means in his specific
context. The goal is to supply a default authority bundle that is easy
to learn, easy to use, and does not supply ("leak") authorities that
would surprise the programmer when someone tried to abuse his grant.
The getParent() method is a perfect example of a surprising leak of
authority that is rarely necessary, and therefore should be exorcised
from any sane API. But getPath()? I claim no programmer would be
surprised to learn his default grant of a File included this.

You may want to get Dean to weigh in on the other side of this argument :-)

--marcs

On Thu, Mar 19, 2009 at 4:44 PM,  <ihab.awad at gmail.com> wrote:
> Hi folks,
>
> In our discussions about a possible file taming for JavaScript, MarcS
> directed us to the E taming. The E taming, about which I was reading
> here:
>
>  http://www.erights.org/javadoc/java/io/File.html
>
> seems to treat the absolute String path of a file as public
> information available to anyone. What it *does* restrict is the
> ability to start from this data and turn it into *authority* -- in
> other words, the ability to create a File from a fully qualified path
> is tamed away.
>
> Given that the JavaScript API is starting (essentially ...) from
> scratch, what would you think of an API that had the following
> properties:
>
> - A "File" object is an opaque pointer to a location in the
> filesystem. Its name, extension, or any other information about it is
> opaque.
>
> - If this File is a regular file, the client may modify, truncate or
> replace its contents.
>
> - If this File is a directory, the client may enumerate its contents
> by name (relative to this directory) and create or delete Files in
> this directory. In other words, file names are not an intrinsic
> property of the File; they are the names by which they are known to
> the enclosing directory.
>
> - Notably, the authority to create or delete a File lies only in the
> directory that encloses it.
>
> This means that it is possible to hand out files (as locations in a
> file tree) without divulging any information about what they are
> called.
>
> It also, however, means that patterns where I am given a file and I do
> different stuff based on whether it is called "*.exe" or "*.txt" can
> no longer work as simply as before. Who does these anyway, and
> are/were they ever a good idea?
>
> Ihab
>
> --
> Ihab A.B. Awad, Palo Alto, CA
> _______________________________________________
> e-lang mailing list
> e-lang at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
>