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

Stiegler, Marc D marc.d.stiegler at hp.com
Mon Mar 23 13:17:02 EDT 2009

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

So, there is indeed a glib problem here, and a couple that are non-glib. The glibness problem is, of course, the dependency of this solution on characterizing during api development all the uses of file names that user interface designers will need 5 years after the api is deployed. My plan for argumentation on this point is, every time someone says, "hey, we'll just add something special to the ui for that special purpose you just mentioned", I will deliver only one more example of yet-another requirement for a special solution, until people get tired. Today, my additional one is, my application is going to send a rich-text message that has a file attachment embedded in one of the paragraphs, and I want to show the contextual path in the embedded location (as programmer of the view on the recipient end, I the best info I can get on the file path is the designator I get from the file, since my user hasn't assigned a pet path yet). Of course, my rich text widget is supplied by the api, and since the api designer was wise enough to allow me to both read and write my rich text widget (otherwise I would have to maintain all the structure info myself and duplicate all the structure info the widget is holding, such as where the line wrap currently is in the current resizing of the panel), this one little piece of the rich text widget must be kept opaque.

Now the non-glib problems are, suppose someone managed to characterize all uses so well you could put them in the api. The best case is, it would make the api a lot larger, a lot more complicated, and a lot different from any ui toolkit ever seen before. You have just created a big barrier to entry.

Can it get worse? Well, suppose you've made this big barrier to usage, but because of a staggering and mysterious change in human nature, the system gains popularity despite it. Do programmers use the file api? No, of course not, it is too complicated. What they do is, every app stores its "files" in its own private space in a custom-built directory system (like Google Docs and Sheets) so that the app can handle its files and its names easily. This blasts all hope of interoperability with other apps to smithereens, but that is a secondary problem compared to making the app able to quickly and easily fulfill its own purposes.


More information about the cap-talk mailing list