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

[Tyler Close]

MarkM wrote:
> At 04:29 AM Monday 3/5/01, Tyler Close wrote:
> >I (Tyler) wrote:
> >> Most web sites don't support reference forking.
> >
> >Given that both E and Joule use the reference forking
> model. I've been
> >persuaded that it's probably "the right choice".
>
> I genuinely was not trying to persuade you when I sought to
> clarify Joule's
> semantics.  Unless you have adequate reasons besides this for being
> persuaded, I must object!  Perhaps it's time for me to take
> on the other
> side of the argument.  /:?

There are other reasons for going with option 5, mostly to do with
flexibility in the implementation. It took me most of the weekend to
get the Droplets code into a position where it can support reference
forking. I'm not too keen about some of the tradeoffs I made. I wonder
if you already know what they are? So, please, tell me your arguments
for the other side.

> That's very cool.  Depending on your attachment to pipelining and
> deadlock-free non-blocking-ness, Droplets may conceivably
> want to wait for a
> round trip from vanilla-web-site-in-VatC-role, to confirm
> arrival of
> message X, before sending message Y to VatB.

Droplets was already doing this when messaging a "vanilla-web-site".
It doesn't have a choice. Neither SOAP, nor
application/x-www-form-urlencoded, support message batching or message
pipelining. I have defined my own application/x-java-serialized-object
protocol that supports both. The target reference determines the
protocol that is used.

> I don't think
> E could afford
> this kind of blocking, but I also don't understand yet
> what, if anything, it
> would mean for E itself to interact with a vanilla web site
> as if it were a
> vat.  I look forward to understanding this.

You only block when the target forces you to block. E talking to E
would not block. E talking to Apache would block.

What part of widely deployed capability applications don't you
understand? This issue is strangely reminiscent of the way FTP text
files bootstrapped the WWW. I know that you have a deep understanding
of the importance of this particular bootstrap operation.

> >This gets rid of both the two-party ordering, and reference forking
> >issues in this thread. The only remaining issue is the
> merging of E's
> >"live" and "sturdy" references into a single "robust"
> reference. The
> >case I made for this merging is unchanged. This final point is the
> >most important one. It underlies all of the distributed code I've
> >written in Droplets. It really makes things a lot easier.
>
> I'm sorry for the delay, but I am certainly planning to
> engage with this
> issue when I have the time to do it well.  I consider it
> high priority.
> Btw, I like the arguments you've been making.

Thank you. Let's get to this soon. I don't imagine we can ask MarcS to
rewrite EiaW too many times. For this reason, it would be nice to also
put the Hydro issue to bed soon.

Tyler