[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