[cap-talk] Persistence as a cap value

[James A. Donald]

Jed Donnelley wrote:
 > > > I wonder if you could give an example of a
 > > > capability that made sense to issue/communicate as
 > > > non-persistent? [...]

James A. Donald:
 > > The capability to access a particular file: my word
 > > processor should not be able to open or modify any
 > > @#$%^&* file it pleases,

Pierre THIERRY wrote:
 > I don't see how persistence of a file capability could
 > enable the process holding it to access "any file it
 > pleases".

I don't see how persistence of a file capability would
be of any use to a word processor.

 > And if I have started a dozen editors on source files
 > and three help viewers on various documentations, I
 > don't want to have to reopen them on restart. I don't
 > even want to have to remember what was open.

My code editing system uses project files, one for each
project.  Each icon corresponds to a file containing a
list of files to be opened, and the current edit state
of these files - but I have to open those project files.
When I open one of these project files, I get an edit
window containing numerous child windows, each
displaying a file that may be edited.

Good software observes certain constraints.
Capabilities need to be provided in accordance with the
behavior models of good software so as to compel bad
software to follow the same constraints.