[E-Lang] not a statement of consensus on ERiaSR versus liveref

[Mark S. Miller]

At 04:54 PM Thursday 4/26/01, zooko@zooko.com wrote:
>I strongly like the idea that you mention of having future-compatibility for
>different retrying/ordering/impatience abstractions in future versions of E.

Me too!

>I personally don't yet grok the issues well enough to know what backwards-
>compatible evolution we would be precluding by deploying a particular
>abstraction...
>
>I feel sure that the experience that several of us have in network engineering
>would enable us to quickly implement a basic version of any new abstraction we
>choose, starting with a working VatTP, and hacking the new abstraction on top
>ofLiveRefs/SturdyRefs/VatTP.

The above two paragraphs seem to contradict each other.  If we're confident 
of the second (which would be great news), then don't we have an adequate 
answer to the first (which would be even better news).

Something I haven't mentioned so far in this discussion, because I hadn't 
realized until just now how important it is:

In order to enable the comm system to eventually be coded in E code given 
appropriate least authorities (rather than Java code in the TCB), ELib now 
exports the interface RefHandler 
http://www.erights.org/javadoc/org/erights/e/elib/ref/RefHandler.html and 
the class Redirector 
http://www.erights.org/javadoc/org/erights/e/elib/ref/Redirector.html .  
These are used together in the upcoming 0.8.10 to implement the eventual 
references RemoteVows and FarReferences, and other can use these to 
implement RemoteVow-like and FarReference-like behavior.  Observe:

    ? def ref__uriGetter := <unsafe:org.erights.e.elib.ref.*>
    # value: <unsafe:org.erights.e.elib.ref.*>

The RedirectorMaker is non-trivial authority, as it enable one to sense 
garbage collection, and so escape determinism and read covert channels.  
Also, using the Redirector, one can make remote references that are ==, even 
though they actually act differently.  So the integrity of == is somewhat 
vulnerable to the misbehavior of holders of RedirectorMaker.

    ? def RedirectorMaker := <ref:Redirector>
    # value: <unsafe:org.erights.e.elib.ref.Redirector>
    
Make a demo implementation of the RefHandler interface:

    ? def printingHandler {
    >     to handleResolution(newTarget) { 
    >         println(`resolution: $newTarget`)
    >     }
    >     to handleSendAll(verb, args) :any {
    >         println(`send: $verb($args)`)
    >         3 <- yourself()
    >     }
    >     to handleSendAllOnly(verb, args) {
    >         println(`sendOnly: $verb($args)`)
    >     }
    >     to reactToGC() {
    >         println("gc")
    >     }
    > }
    # value: <printingHandler>

RedirectorMaker's one argument constructor will make a reference that seems 
to be a RemoteVow (eventual, remote, and unresolved).  The two argument 
constructor, when the second argument is non-null, will make a reference 
that seems like a FarRef (eventual, remote, and resolved), with the second 
argument tagging the distributed sameness identity.

    ? def rdr := RedirectorMaker new(printingHandler)
    # value: <Pointless Redirector>

    ? var ref := rdr getHandledRef()
    # value: <Eventual ref>
    
    ? rdr
    # value: <Open Redirector>
    
    ? def xPromise := ref <- foo("carol")
    send: foo(["carol"])
    # value: <Eventual ref>
    
    ? xPromise
    # value: 3
    
    ? ref := null

(MarkM clears some interactive interpreter state holding on to previous 
results)

    ? <unsafe:java.lang.System> gc()

    ? 
    gc
    ? 

So if the comm system can be implemented by non-privileged code, then there 
can be multiple comm systems in a vat, and these can be independent or build 
on top of each other as they choose.  The above elmer transcript should 
demonstrate that user-defined ERiaSR references can be made to respond to 
"<-" in just the way live references currently do.

I think this is consistent with Droplet's take on behavior conditional on 
the kind of reference.  Tyler?



>I'm sorry about the delays in my contribution to this discussion, and I hope
>that it doesn't time out.  Hopefully we can effectively parallelize so that this
>issue doesn't hold up E deployment.

This issue isn't holding me up.  I'm proceeding towards an 0.8.10 CatTP with 
a fully pipelining protocol.

A funny thing about protocols is, more than for most programming, you gotta 
do a bunch of documentation up front just to keep things straight in your 
own head.  Designing CapTP-like protocols have always been intensely 
topological exercises.  CapTP and its predecessors were worked out using 
"whiteboard animation" (drawing successive steps of a sequence by 
transforming the drawing in place.)  But this time, we can all see these 
animations.  Check out http://www.erights.org/elib/distrib/captp/index.html 
for the root of the draft documentation, and 
http://www.erights.org/elib/distrib/captp/DeliverOp.html for a cool 
"whiteboard" animation.  Please view with IE5, rather than Netscape or 
Opera, as IE5's double buffering makes all the difference.



        Cheers,
        --MarkM