[cap-talk] Persistence as a cap value

[Jed Donnelley]

On 3/14/2008 11:27 AM, Raoul Duke wrote:
>>  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.
> 
> ja! even ignoring capabilities, this is I think a truly important
> thing from a usability standpoint: Jef Raskin++.

I can well understand this.  For example, I like (though don't
always use) Firefox's relatively new feature of recovering
all it's "sessions" (viewings?) when it recovers from being
uncleanly restarted.

However, I'm afraid I've lost how the above ties into the
notion of persistence for capabilities.  To me the above
suggests an argument for more persistence (e.g. for
Firefox's saved URLs still working at some future time),
but as I recall it was brought up as an argument
against persistence.

Would anybody like to complete the loop and tie the above
into an argument for or against persistent capabilities
in whatever circumstances?

I'll restate my current understanding, from what I've
read here so far, to guide that argument:


Non persistent capabilities (those who can be lost on
an asynchronous event like the restart of a process
or system) can be useful and convenient IF it
can be arranged that the capabilities are lost by
any such event no sooner than any programs (or people)
using the capabilities might legitimately access them.

Otherwise (in most circumstances I think?) capabilities
should be persistent and explicitly managed (e.g.
revoked as needed/appropriate) - as long as the
costs of supporting persistence isn't so high as
to out weight the costs of potential access failures
due to asynchronous capability invalidation.


I confess that I have an abhorrence to timing
dependent situations.  The only thing worse than
an explicit timeout is a "random" timing dependence
(e.g. like not knowing when a process or system might
be restarted and cause some of my capabilities to
become invalid).  My general approach to a timing
dependence is to push it down to as low a level as
possible (e.g. this send or receive didn't complete
even though we waited as long as we possibly could.
What would you like to do General sir?).  From my
perspective influences from asynchronous events
(e.g. that system over there restarted so my
capability to one of its objects just became
invalid) are to be avoided if possible.  Persistent
capabilities in my view help with this.  Their
costs are those due to their implementation.  In
this regard I see persistent capabilities much
like persistent files - whose recovery costs on
system restart I hope we agree are worthwhile.
Of course in some sense this is natural as the
file is of no use without a capability to it.

My biases above are of course influenced by many
years of work in an environment where files and
capabilities to them were the only means of achieving
any "persistence" at all, so other environments
where persistence may not be valued are foreign
to me.

--Jed  http://www.webstart.com/jed