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

[zooko@zooko.com]

 I, Zooko, wrote:
>
> 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.


I shouldn't have written sloppily like this -- mentioning a set of messages upon
which we may impose an ordering guarantee by naming the receiver but leaving the
question of sender ambiguous.  (It was just such ambiguity that gave rise to the
replay attack against the stock market.)


So which specific set of messages do I mean? ...


A-ha!  Interestingly, the problem of resource management only applies if we
specify that there is an up-to-here ordering guarantee for all messages sent
*from this Vat* to *a given unique counterparty*.

This is because an unbounded amount of messages can pile up for a given
counterparty, but if the counterparty doesn't come back on-line they can never
be cleaned.


But if we define an up-to-here ordering guarantee for all messages sent *from a
sending object* to a given unique counterparty, then the programmer can indicate
that he no longer needs the ordering guarantee by forgetting all references to
the sending object.  When the sending object is garbage collected, we can safely
forget all the unacknowledged messages without violating the guarantee.

I'm not confident that this would be a clear, safe abstraction, however,
because, for example, a programmer might want to send a message from object A to
(remote) object B, and he wants that message to get reliably delivered, but
otherwise he has no use for object A and he allows it to get garbage-collected,
thus inadvertently allowing the message to go undelivered.


My current feeling is that a good safe abstraction for reliable delivery needs
to make a very explicit and clear way for the programmer to know about, and to
control, delivery.  For example, an eventually operator whose executable object
persists until either you receive an unforgeable acknowledgement that the
message was delivered, or the programmer explicitly decides to abandon the
delivery attempt with a "give up" sort of command.


Now you can also define the set of messages to be all messages sent *from
anywhere in the universe* to *a given capability*, but I can't see any way to
implement an up-to-here ordering guarantee on that set.

You *can* however implement a no-late-messages ordering guarantee, as MarcS has
demonstrated in the Stock Market app, by sending a "Do not process any old
messages that don't come with a proof of fresher-than-this-one." message.  (This
is effectively what current VatTP implements, where the freshness proof is in
the per-connection message numbers and the randomly chosen DH exponent, and the
"-than-this-one" is in the "which connection is the message on" logic.)

This is useful (as MarcS's stock market example shows) if you also have an
up-to-here ordering guarantee for the set of messages which includes the "Do not
process..." message.  (And again, VatTP supplies this by its up-to-here ordering
guarantee per connection.)


Regards,

Zooko