Lex Spoon wrote:

>
> Second, method invocation is a bit of a misfit for networks, which are
> based on disconnected sends and receives.  It's bad to do a send and
> then have to wait for a reply, so direct RMI is probably not the best
> strategy.  RMI with "promises" might be workable, but it's tricky.  What
> happens if the return value is actually an error?  Oops, you shouldn't
> have kept executing!

No.  The design should only have to consider the error at the point the
promise's value is first requested.

I like promises best, since they maximize opportunities for parallelism.

> Guaranteed transmission and in-order arrival both impose constraints on
> the network and tend to degrade performance.

They're the most useful defaults, though.

> In a system with broader scope, you
> might have a morph on each end of the connection that is lazily updated
> as things change.  Help with automating things like this synchronization
> problem would certainly be nice.

Once you try to share state you generally need to guarantee that all
participants see the same sequence of events on that state.

If you're going to go that route, it's worth looking at "causal broadcast"
style algorithms.

-dms