[E-Lang] remote comms

[Chris Hibbert]

I was having trouble with my email at the beginning of the month, and
I'm only now trying to skim the archives.  This message is replying to a
conversation zooko started two weeks ago.  

I've recently working on a project in which we've been using ELib from
Java.  I have been responsible for writing the wrappers that are
intended to make proxies and promises palatable to ordinary Java
programmers.  (Though I should admit that they're unordinary enough to
have bought fairly rapidly Dean's arguments about distributed semantics
and the need for an event-based style in order to build reliable
deadlock-free systems.)  I've just delivered my code, examples and doc
to the customer, so there's no feedback yet on how palatable it will
turn out to be.

Dean did much of the design, but since I did most of the implementation,
I have some comments on the kinds of issues Zooko raised.

Our (speaking for Dean and myself) recommendations for using remote
references equate to recreating a LiveRef from a SturdyRef at the
beginning of every small-scale transaction.  We've hidden from the
developers the problem of ensuring that there's a live connection to
each server that a component relies on.  We've provided them with a
single call that asks for a proxy for any particular service they rely
on, and recommended that they re-use it throughout a transaction, but
ask for a new copy when they receive a new request.

One of the pieces we haven't implemented yet that these developers will
definitely need is a simple invocation for time-out logic for
practically all remote messages.  I think this is the same need that
zooko is talking about with his impatience logic.  In our application,
all (user-initiated) requests will have explicit requirements-driven
need to timeout and return a default answer.  In our context (making
access control decisions) the default answer is that if we haven't
received the information to make a positive decision in a certain amount
of time, we forbid access.  The distributed components are working
together to reach this decision, so it could just be the code that talks
to the user that times out.  We'll probably have time-outs in most of
the components so they take a limited amount of time and don't waste
computrons on hard questions that the requester has given up on.

My intuition today is that it should be simple to build both promises
that have an explicit time-out and ones that don't.  The latter
shouldn't time out any sooner than the underlying mechanisms (e.g. TCP) require.

Chris