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

[Jed Donnelley]

On 3/12/2008 2:11 PM, Karp, Alan H wrote:
> Rob Meijer wrote:
>> So my (initial) stand on this topic would currently be 'dont try to do
>> persistent delegation with non persistent processes'.
>>
>> I am very interested to hear alternative views on this.
>>
> Client Utility was a c-list system that took a half-way approach.
> Each entry in the c-list referred to an inbox.  A client (aka process)
> with the right capability could connect to an inbox and become the
> handler for all c-list entries that pointed to it.  A message that
> could not be delivered to a handler, because the inbox was gone or
> not connected, returned an error.
> 
> A given client could be declared persistent or non-persistent.  A
> persistent client could make either persistent or non-persistent
> entries in its c-list.  The persistent entries in a c-list were
> preserved across restarts.  We introduced that approach for
> resource management purposes, but the mechanism proved to be useful
> for other things.  For example, a programmer could explicitly
> control a persistent client's restart state.

When you say you introduced that approach for "resource management
purposes" I guess you mean that persistent c-list entries were
more expensive somehow?  How did you deal with lost objects and
their potential costs?  I consider the issues of lost objects and
"lost" (whether legitimately 'lost' or just disabled by a restart)
capabilities related.

While I can understand the value of starting a system in a known
consistent state, I find it difficult to appreciate the value of
capabilities whose operation can be seemingly capriciously changed
by a system restart.  To me persistence if only an issue because,
while valuable, it may present some difficulties to implement.

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