[prev in list] [next in list] [prev in thread] [next in thread] 

List:       e-lang
Subject:    Re: [E-Lang] Remote Object E Question
From:       zooko () zooko ! com
Date:       2001-08-27 17:06:03
[Download RAW message or body]


I'm sorry that I have not had the time to follow e-lang recently.  (I am
writing this one-handed while rocking a sleeping baby in my arms.)

In my opinion path shortening should be delayed until the sent-but-not-acked
messages are flushed in order to more fully enforce the partial ordering
guarantee that programmers will rely upon.  That is: if I send a message to
Alice saying "Remove key K from the database.", and then I send a message to
Bob containing a reference to the Alice-who-has-already-received-the-
"remove"-message, then I ought to include as little information as possible
which might enable Bob to access the Alice-who-has-not-yet-received-the-
"remove"-message.  Therefore, I should not share Alice's Vat ID with Bob until
I'm sure Alice received the "remove" message.

As a practical matter it might actually be faster that way as well, as Bob can
use his extant TCP connection to you, and you your extant TCP connection to
Alice, instead of blocking on the TCP connection setup from Bob to Alice.
(And then he can path-shorten after the connection is setup, which tends to
nicely coincide with Alice acking the "remove" message.)


But that is a tiny performance detail.  The big issue to me is that immediate
path shortening gives Bob information which in a typical application may enable
him to violate the partial ordering expectation of the programmer (if not, as
MarkM can explain, the *actual* letter of the partial ordering guarantee, which
is more narrowly defined).


I apologize if this message is inappropriate or redundant -- e-lang messages
have been swelling the size of my "Read This Later" folder...


Regards,

Zooko

_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang

[prev in list] [next in list] [prev in thread] [next in thread]