[cap-talk] 'Destroy' vs 'Sever'

[Jed Donnelley]

At 05:03 PM 11/27/2007, Charles Landau wrote:
>At 4:26 PM -0800 11/27/07, Jed Donnelley wrote:
> >On 11/26/2007 9:11 PM, Charles Landau wrote:
> >>  At 3:37 AM +0000 11/27/07, David Hopwood wrote:
> >>>  ...So the presence of the Sever operation implies that
> >>>  this composite is not defensively consistent.
> >>
> >>  I repeat, Sever is not an operation on the object. Therefore clients
> >>  cannot Sever.
> >
> >I'm afraid I'm still a little lost with the above.
> >If a "client" can't issue a Sever request, who can?
> >Aren't all requesters in some sense "client"s?
> >How is a Sever request authorized?
>
>In KeyKOS/EROS/CapROS, you call a SpaceBank saying "Sever this
>node/page that you created".

When you say "call a SpaceBank", using what capability?
Not the node/page capability apparently.  Is there a
separate 'SpaceBank' capability that is used for this
communication?

> >On 11/27/2007 11:26 AM, Charles Landau wrote:
> >>  the purpose of Sever is only to do clone and destroy more
> >>  efficiently. For the many objects that don't have internal references
> >>  to the root, it can be very efficient.
> >
> >The above makes some sense to me except for the reference
> >to "the root".  Can you describe what "the root" is in
> >the above context Charlie?
>
>I was referring to:
>
>At 3:37 AM +0000 11/27/07, David Hopwood wrote:
> >Consider an implementation of a composite data structure, say something
> >like a tree, with one visible facet representing the root. An operation
> >on this facet may delegate to one of the internal objects. Suppose that
> >under some circumstances, an internal object needs to call back to the
> >root object in order to maintain a global invariant of the composite --
> >for example to rebalance the tree.
> >
> >Now the root object is severed. The internal objects still have references
> >to the old root, but they cannot be successfully invoked.

Ah, thanks.  Now I think I understand more the sense
of the discussion.

--Jed