[cap-talk] Virtualizability vs. Synergy
David Hopwood
david.nospam.hopwood at blueyonder.co.uk
Sun Jul 9 09:29:15 EDT 2006
Norman Hardy wrote:
> I wrote some short notes on Virtualizability vs. Synergy at
> <http://cap-lore.com/CapTheory/Patterns/CapParam.html>.
> My description of virtualizability in Keykos is still scanty.
# In each synergy pattern I rely on some other object that I did not get
# from you to tell me whether I can safely use P. I pass P to it and it
# replies yes or no.
This is less general than asking the 'other object' to return a wrapper
for P. A wrapper can enforce that P dynamically follows any given protocol,
without knowing its implementation. A vetter usually needs to recognize or
analyse P's implementation in order to show that it has the desired properties.
(I believe Joule used the wrapper approach, calling these objects "verifiers".)
> It is part of the issue of whether platforms should provide "Eq?".
> Dean Tribble has stories about how to solve without synergy, some of
> the problems that Keykos solves with synergy,
> I cannot recall the details.
My current understanding is:
- it is possible to define wrapper-style and vetting-style variants of all
known rights amplification/synergy mechanisms, including grant matching;
- EQ (or another vetting-style mechanism as a primitive) is needed to
express each of the vetting-style variants;
- neither EQ nor any primitive rights amplification mechanism is needed to
express the wrapper-style variants -- for example, they can be expressed
in the pure actor model without EQ, by using the Joule verifier protocol:
<http://www.eros-os.org/pipermail/e-lang/2001-October/005855.html>;
- EQ is mostly harmless. Although it interferes with transparent forwarding,
this is usually not an important issue;
- EQ is convenient to make implementations of (even wrapper-style) rights
amplification more efficient and simpler. It's also familiar to, and
expected by, users of conventional OO languages.
--
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>
More information about the cap-talk
mailing list