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

[Rob Meijer]

On Wed, March 12, 2008 17:32, Jed Donnelley wrote:
> At 04:19 AM 3/12/2008, Rob Meijer wrote:
>>If a system reboots, the people involved remain persistent,
>>the program code remains persistent, but the programs involved
>>are new instances of this code, possibly started with different
>> parameters
>>and/or run in an other context. The notion of a process being an
>>incarnation of a 'persistent' program is therefore unnatural, and thus I
>>feel persistent delegation is not directly suitable.
>
> When you say "not directly suitable" in the above, do you mean
> "not readily achievable" (i.e. this is an implementation issue)
> or do you mean "inappropriate" (namely there is something about
> persistent objects that would cause a problem)?
>

I may have been insufficiently clear in my wordings. What I meant to say
is that on systems that allow multiple instances of a program to exist and
exist in different contexts, the 'simple' approach of simply mapping the
program 1 on 1 to a (pseudo) persistent process would be unnatural, and
yes in most cases inappropriate.

>
>
>>As I am trying to do in my MinorFs project, I do however feel that a
>>(pseudo) persistent process concept would allow the processes to act as
>>naturally persistent objects, thus enabling persistent delegation.
>
> I believe I understand the above - though the use of the qualifier
> "pseudo" seems a bit odd to me.  If there is something worth expanding
> on there I'd be interested to hear.  However, regarding:

What I mean with "pseudo" persistent is that it might be sufficient to
allow the programmer to explicitly explicitly claim (partial) persistence
(in a way like Alan described) rather than building a system that
implicitly provides persistence to processes.

Rob