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

[David-Sarah Hopwood]

Stiegler, Marc D wrote:
>>> [...] 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).

My position is that it's perfectly reasonable for an app that is
granted access to a file to, under normal circumstances, also be
given a name for that file. However, it should not normally be given
its path (or the path by which it was accessed in this case, to be
more precise).

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

Regardless of the name/path issue: the two UI features described above
are not special-purpose; they have been present in essentially all GUI
frameworks since GUIs became popular. No crystal ball is required to
anticipate their usefulness.

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

Existing applications don't do that: if I attach a file in Thunderbird
or Outlook, or if I paste a file reference from Windows Explorer into
Microsoft Word, it shows only the name, not the path. The path would
usually be too long, and not very useful.

I don't see why capability-based APIs should be held to requirements
that are not needed by existing non-capability apps.

> Now the non-glib problems are, suppose someone managed to characterize
> all uses so well you could put them in the api.

No-one needs to characterize all possible uses of path information.
If all I do is select a file to be given to an app using a powerbox
file chooser, then that action is not authorizing the app to know the
path, and so it can't have it. Period.

There may not even be a meaningful absolute path for a given file, so
if an app were to rely on knowing such a path, it would be incorrect.

-- 
David-Sarah Hopwood ⚥