[cap-talk] In Defense of Identities - not

[Toby Murray]

The material from these classes isn't perchance available anywhere, is
it?
(Or is it in Walnut already?)
It sounds like it would be a great source of info for E programmers and
object-cap practitioners in general.

On Thu, 2006-12-07 at 09:51 -0800, Marc Stiegler wrote:
> Nice questions. Having built 5 different membranes for a class I taught 
> on object-caps using E, I can answer these questions at least when using 
> language, not os, for enforcement:
> 
> -- "A revokes cap 'c'. Does C still have it?" The answer with all 5 of 
> the membranes I wrote is, C still has 'c' (this assumes that Bob has a 
> true 'c' to begin with, if B only had a copy of 'c' from A controlled by 
> the same membrane, both C and B have all copies revoked).
> 
> --"Should the wrapping be implicit in the transport?" Answer in all 5 of 
> my membranes: yes, the wrapping is implicit in the transport. Otherwise 
> it is error prone, and so difficult to use no one would use it.
> 
> --"What are the implications for EQ and EQUAL?" This question is made 
> complicated by the fact that EQ and EQUAL vary in meaning from language 
> to language :-) However, in the 5 E membranes, the answer varies from 
> membrane to membrane. The simplest does not preserve EQ or EQUAL for 
> anything. Three of them preserve EQUAL for pure data. The most 
> complicated membrane preserves EQ across separately manufactured copies 
> of the reference to 'c' created by the same membrane, but does not 
> preserve EQ across membranes, or between the membraned 'c' and the 
> original 'c'. I don't immediately know of a way of implementing a 
> membrane that would directly support the built-in EQ for cross-membrane 
> comparison, though it is easy enough to imagine a separate pattern that 
> one could support, similar to a notary/inspector pattern, that would 
> perform EQ across multiple membranes and 'c' itself, if one were the 
> owner of both 'c' and the membranes.
> 
> So the real answer is, pick a membrane that meets your needs. Which, 
> alas, is no answer at all if one is trying to pick the one true membrane 
> to be used by the OS :-) Is there something wrong with the membranes in 
> KeyKos? Or did I miss that part of the discussion?
> 
> --marcs
> 
> Jonathan S. Shapiro wrote:
> > On Wed, 2006-12-06 at 15:44 -0500, Jonathan S. Shapiro wrote:
> > 
> >> 1. Introducing a wrapper is incredibly expensive (thousands of cycles).
> > 
> > And when you think about it, this is quite a nasty statement. If
> > membranes are a frequently manipulated pattern this will almost
> > certainly perturb the OS, because it means that for efficiency reasons
> > the OS must have explicit cognizance of membrane domain boundaries.
> > 
> > This in turn means that we are introducing an entirely new capability
> > model, because one of the operations (we may want others) takes the
> > form:
> > 
> >   domain->revoke(cap)
> > 
> > and we don't want to search the domain to hunt them down. This is quite
> > a serious mess.
> > 
> > But there is a bigger problem. I haven't heard anybody articulate a
> > sensible algebra for membrane construction. Consider processes in three
> > different revocation domains A, B, C.
> > 
> >   A sends cap 'c' to C.
> >   B sends cap 'c' to C.
> > 
> > A revokes cap 'c'. Does C still have it? Which copies? Must the sender
> > be explicitly aware of membrane domain boundaries, or should the
> > "wrapping" be implicit in the transport? What are the implications for
> > EQ and EQUAL?
> > 
> 
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk