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

[Karp, Alan H]

Jed wrote:
>
> When you say you introduced that approach for "resource management
> purposes" I guess you mean that persistent c-list entries were
> more expensive somehow?

Each resource had a repository entry that typically was 100 B to 1 KB.  We were concerned with the total size of the repository.  Of course, that was in the days when a 10 GB disk was considered huge.

> 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.
>
Clients had quotas and were charged for the space used when they created an entry or modified an existing one.  We had a garbage collection algorithm for unreachable objects that was far simpler than any of us expected.  The algorithm relied on our use of path-based capabilities, i.e., "no introduction by default", which differs from what everyone else does.
>
> 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.
>
The programmer decided which capabilities should survive a system restart for each application.  The system did nothing special to rebuild a consistent global 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



> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of Jed Donnelley
> Sent: Wednesday, March 12, 2008 2:54 PM
> To: General discussions concerning capability systems.
> Subject: Re: [cap-talk] Persistence as a cap value (was: Re:
> ...PLASH discussion)
>
> 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/
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>