[E-Lang] Remote Object E Question

[Mark S. Miller]

At 08:44 AM Sunday 8/26/01, Marc Stiegler wrote:
>(but I haven't run this
>piece of email through E, so it probably contains a syntax error and a
>runtime error somewhere),

Naughty naughty!


>class revokerCapabilityPairMaker new(baseCapableObject) :near {

Should be 

  class revokerCapabilityPairMaker(baseCapableObject) :near {

Since "class" provides the "new" for you.  Alternately

  def revokerCapabilityPairMaker {
      to new(baseCapableObject) :near {

is fine if you want to provide it for yourself.

>    var capableObject := baseCapableObject

You actually don't need two separate variables.  If you declare your 
parameter variable "var", it will do the job:

  class revokerCapabilityPairMaker (var capableObject) :near {


>    def revoker {
>        to revoke() {capableObject == null}

That should be

          to revoke() {capableObject := null}

And after I'd gone through all the trouble to make assignment be ":=" just 
so people would stop making this mistake. ;)


>    }
>    def forwarder {delegate {capableObject}}

The crucial thing to know about this forwarder definition is it doesn't 
forward any of the Miranda Methods 
http://www.erights.org/elang/blocks/miranda.html , 
http://www.erights.org/javadoc/org/erights/e/elib/prim/MirandaMethods.html .
This is important, as some of these Miranda Methods ('yourself' and
'whenMoreResolved') would have given direct access to the object.  If you do 
wish to forward some of these, let's say 'printOn', you'd do it manually as:

      def forwarder {
          to printOn(out) { capableObject printOn(out) }
          ...
          delegate { capableObject }
      }

Given the purpose of revocation, the Miranda messages it's safe to forward are:

    getAllegedType
    respondsTo
    order
    whenBroken

    printOn
    reactToLostClient

Although there's usually no need to forward 'getAllegedType', 'respondsTo', 
'order', or 'whenBroken', and a general purpose revocable forwarder 
abstraction should probably not do so.

We might call the result of all this "cooperative revocability" -- this 
successfully revokes access to an object that doesn't do anything 
(accidentally or maliciously) to thwart our attempt to prevent direct 
access.  For example, the object must not give itself out as the result of 
any messages that might still be forwarded to it.

When we can understand the documented protocol of the object, and when we 
believe it (we're not worried about bugs or subterfuge), but some of these 
methods are documented as giving out self (or a similar level of authority 
we don't want our clients to hold directly), then we can design a custom 
forwarder that takes this protocol into account.  Let's call this 
"cooperative custom revocability".

<detail>
For the uncooperative case, we'd have to use a different pattern that's been 
referred to on e-lang by various names, including "membrane" or 
"compartment".  Just as our above forwarder is a "Man in the Middle" (MITM) 
between our client and the capableObject, a membrane starts in the middle, 
but then looks at all messages going in either direction and wraps all the 
capabilities in a new membrane-forwarder, thereby extending the membrane as 
the surface area of capableObject and the objects gotten from it grows.

The E vat mechanism includes a full membrane implementation, not for 
purposes of revocability, but for purposes of stretching these surface-area 
capabilities transparently over the wire.  This code is currently most of 
the way through a significant refactoring, but the result should be usable 
for membrane-revocability as well.  The vat code already supports the notion 
of partition (the spontaneous severing of all capabilities between a pair of 
vats).  Membrane revocation is essentially an induced partition.  To a first 
approximation, you'd put the above forwarder alone in its own modified vat.  
When you want to revoke not just the forwarder but the whole membrane, you'd 
kill this vat rather than just revoking the forwarder.

Alan, you may be amused that the main modification to the CapTP needed to 
support this is the option not to shorten 3-vat Granovetter introductions, 
much as E-Speak2.2 did not.  Were these shortened, they would not be revoked 
when the original vat was killed.  Precisely my argument for shortening -- 
that the capabilities should not be vulnerable to the death of the 
introducing vat -- is here the reason not to shorten.  Of course, for 
grant-matching reasons, unshortened capabilities cannot present the sameness 
identity of the object they forward to.  Therefore, they will probably 
remain unresolved, which is a bit weird but correct.  (Unshortened 
E-Speak2.2 could not support grant matching for the same reasons.)
</detail>


        Cheers,
        --MarkM