[E-Lang] New Page: Partially Ordered Message Delivery

[Tyler Close]

Alan Karp wrote:
> We decided that it should be a policy decision based on who
> you're talking
> to as to which behavior you got.  Where we expected the
> connection to be
> there, all references were kept and were immediately available on
> reconnection.  Where the connection was ad hoc, the
> references were thrown
> away when the connection was lost and had to be rebuilt if
> the machines
> reconnected.  We also discussed a continuum of policies
> based on leases but
> decided to stay with two modes of operation until we saw a
> need for more
> flexibility.

In Droplets, all "sturdy" caps are exported from a particular context,
called a "Messenger". When the "Messenger" dies, it takes all of its
exported caps with it. The decision you are talking about is the
decision of which "Messenger" to export a cap from, and when to kill
off that "Messenger". By default, connection to a particular Vat
(called a "Cistern" in Droplets parlance) results in the creation of a
Messenger that will be killed off after the connection has been idle
for a preset amount of time. A server side object, that a client
interacts with, may choose to export a return value from a different
Messenger, giving that return value a different definition of
lifetime. It is my hope that this mechanism of intersecting contexts
(Messengers), will prove flexible enough to implement a wide variety
of policies.

Tyler