VNC Server

Lex Spoon lex at cc.gatech.edu
Mon Apr 17 17:26:59 UTC 2000


> > Okay, this might be workable, assuming the programmer is prepared for
> > it.  But it's certainly not normal--If I retrieve an HTML page and get a
> > promise back, I'm liable to start creating a browser window to display
> > it in.  If there turns out to be an error, then I've made a mistake by
> > even *starting* to open the window.
> 
> I don't think so.  The window's an ideal place to post a error message to
> the user indicating that the HTML page isn't available.

Hmm, we're not going to agree any time soon.  I think you'll often want
to check whether the operation succeeded fairly quickly.

But we're straying from the original point.  Even if you wait until
you open the window to check the return value, you probably haven't waited
long enough.  It will be at least a few milliseconds before the result
comes back, and if the result is big, it might be several seconds.

It would be much better to display some "waiting" graphics while waiting
for the data to download, all errors aside.  But now the calling code
is explicitly aware of the fact that a message send is really just a
send/receive pair in disguise.  Did we gain enough from disguising it,
that it is worth this kind of coding?  I dunno.


> > As a small detail, it also doesn't let you do "x zap" and get a promise
> > cascaded on the original....
> 
> Why not?
> 
> Clearly, the message "zap" can't actually execute until "x" gets a value.
> If the evaluation of "x" fails, then the evaluation of "zap" must also fail.
> An implementation could be constructed, though, in which the evaluation
> of "zap" immediately follows the successful arrival of a value for "x".


You actually can send zap immediately.  The distributed object system I
put together would let you do this, for example.  All you have to
do is have the remote side remember which promises it has
fulfilled for a little while.

In fact, many otherwise expensive operations can be executed very
quickly by cascading messages like this--the messages end up being
pipelined over the network connection.  "x a b c d e f" ends up sending
a, b, c, d, e, and f back to back over the network.  Eventually, the
remote side will send back all six answers back to back.  With
synchronization, the #b doesn't get sent until #a's answer comes back,
and so on.

So the ideal scheme for working with promises, it seems to me, is to
simply have points where the user can explicitly synchronize the
value.  Then, a good programmer just inserts the checks at appropriate
critical points, and otherwise lets the system run at maximum efficieny.

Anyway, to beat my dead horse one more time, you'd still need to know
which objects are potentially remote.  For example, you can't just swap
in a RemoteCanvas, until the world's drawing code is explicitly
modified to deal with potential network failures.


-Lex





More information about the Squeak-dev mailing list