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

zooko@zooko.com zooko@zooko.com
Thu, 26 Apr 2001 18:26:49 -0700


 MarkM wrote:
>
> >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).

Well I meant backwards-compatible in that code written to E 1.0 would be
guaranteed to do the same thing on every release of E at least up to but not
including E 2.0.

For example, if we defined up-to-here ordering guarantees for every SturdyRef,
this would be constraining us because programs would depend on that guarantee,
and then if we wanted to loosen that guarantee (as we indeed would for
memory management reasons as Jonathan pointed out, if not for other reasons) we
would be breaking backwards compatibility.


Hm.  I can't think of any obvious backwards-compatibility problem with defining
comms abstractions to be as currently defined, with a fix for the "context in
which ordering is guaranteed" to fix the Zooko-Wagner-Stiegler attack on the
stock market (but not the much cooler Hartley attack on timing in markets).


I am going to try to think about backwards-compatibility issues in deploying the
current abstraction (+ fix)...


The facts about making the ref behaviour accessible in E code is great news!
Very exciting!  I have often thought woefully that I could make the comms do
whatever I wanted but at the cost of having method-invocation syntax i.e.
`alice.send("openDoor", args)' instead of `alice <- openDoor(arg1, arg2)'.

This fixes that complaint!


Regards,

Zooko