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

[Karp, Alan H]

Jed wrote:
>
> I wonder if you could give an example of a capability that made
> sense to issue/communicate as non-persistent?

Jonathan's example of a remote user is one.  That user can create transient resources (think temp files) and their corresponding capabilities that all vanish when the connection is broken.  Those capabilities are useful to that client even if they're not sent to anyone else.

The transient capabilities may be sent to another client for later use.  The sender has no control over when or whether the recipient will use the capability.  If the capability is sent as part of a transaction, the guarantee that the capability disappears on system restart makes supporting transactional semantics easier.

Transient capabilities are also useful for the recipient.  In Client Utility, the c-list was actually stored in a set of "frames".  A received capability stored in a non-persistent frame would not appear in the client's c-list after the frame vanished.  That allowed a programmer to control the permission state when the program was restarted.

________________________
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