[e-lang] File API taming

[Kevin Reid]

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  
*was* gotten.

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  
Capability.

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/>