[cap-talk] [e-lang] File API taming
kpreid at mac.com
Sat Mar 21 21:27:17 EDT 2009
On Mar 19, 2009, at 21:35, Marc Stiegler wrote:
> 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.
[copying-and-redirecting-to cap-talk because this message has become
general capabilities/UI stuff, not taming design]
Here is a glib answer, and a ramble, for further argument:
The application should not need to know the name of the file. In the
case of one-window-one-file document editors, this is simple enough;
let the system UI layer -- CapDesk in this case -- display the name of
the file in the title bar.
In more complex cases where the application works with file objects
and needs to do things like presenting them in a list to the user --
let the application ask the UI layer for a widget which displays a
file reference (name and icon, perhaps).
Now, what is "the name of the file"? If possible, it is a petname for
that file, or the petname of a known directory which contains that
file -- possibly recursively, if that's feasible. If no such path is
possible, then record in the file-reference the path by which the file
There will probably be situations in which you can't possibly know any
name of the file -- for example, it was anonymously created, or handed
to you by some somehow-noncooperative other process, or passed by
reference over a network. In this, the best the UI *can* do is to note
its identity and start keeping track of it to be able to distinguish
it in the above UI components.
If it wasn't obvious, I think an important component of a true
capability desktop will be noting reoccurring references and
identifying them for the user, and retaining them. Unlike a capability
program that will be tested and debugged, we can't rely on humans not
to close windows and therefore drop references they turn out to want
later. We need a *history* -- like a web browser history -- of
references previously acquired.
So how do you name a nameless file? Assigning serial numbered petnames
like "untitled-359" would be bad. Think about it as *history* and you
get "untitled file reference received in email January 14, opened once
on January 15 using caplet CapPaint, immediately after working on
<other file> in directory Company Web Site". Now we know a lot about
it, no? Packing this into a window title bar wouldn't work, but a
condensed form would -- paint document icon, text something like
"untitled from Jan 14-15" -- and have it so the additional context is
displayed around it on mouseover, or some other easy gesture.
Having this information visible to the app would obviously be a POLA
violation -- it *must* be implemented in the trus^Wrelied-upon UI
layer. But look at the system you get from it -- it is very much in
the modern style of application design (automatically storing info,
date ordering, carefully interactive information displays, etc), and
*works with every application* precisely because Everything Is A
If we try to build a true capability desktop *without* decent
facilities for helping users hang onto references and remember what
they are -- then we will have a system with obvious hazards and
unobvious benefits compared to the status quo.
(Whew. This didn't go quite where I had planned. I hope it's
reasonably clear and coherent.)
Kevin Reid <http://homepage.mac.com/kpreid/>
More information about the cap-talk