[cap-talk] Persistence as a cap value (was: Re: ...PLASH discussion)

[Jed Donnelley]

On 3/12/2008 10:24 AM, Raoul Duke wrote:
 >>  And an argument can be made that process persistence is the wrong
 >>  default. To the extent that programs are known to be buggy, it may
 >>  actually be important to restart them periodically purely to clear out
 >>  accumulated muck. Persistence adds a lot of pressure for correctness,
 >>  and human programmers don't seem to be very good at that.
 >
 > the "crash only" approach to thinking about software design has always
 > intrigued me, especially since I've heard of interesting, good, robust
 > uses of it in industrial applications (airplane software, telecoms).
 > there are a few different versions of the approach. some have the
 > processes restarting every so many milliseconds!

I have to wonder if going off into the 'weeds' can adversely
effect program performance after a restart time, why not
between restarts?  I consider such problems simply bugs
that need to be corrected, regardless of timing.

On 3/12/2008 10:26 AM, Raoul Duke wrote:
>>  it would seem to me potentially safer to 'prove' that something
>>  short-lived is safe vs. hoping that you don't go off into the
>>  statespace weeds over the days, months, years of uptime.
> 
> tho, if the persisted state can badly infect the restarted processes,
> one might not gain so much.

Which brings us back to persistence for capabilities.

So far it still seems to me that all I've heard is discussion
about implementation difficulties.  Is there general agreement
that:

1.  Persistent capabilities (distributed or not) are a
good (valuable, worthwhile, etc.) facility to have.

2.  If persistent capabilities are available (in whatever
context, i.e. they can overcome any implementation problems
and be made available), then "permanent" (not timing or
system restart dependent) access control management
'should' (loaded word of course I know) be done using
such persistent capabilities.

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