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

[Karp, Alan H]

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.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
http://www.hpl.hp.com/personal/Alan_Karp