VNC Server

Henrik Gedenryd Henrik.Gedenryd at lucs.lu.se
Wed Apr 12 07:20:55 UTC 2000


Lex Spoon wrote:

> However, I see a problem with transparent distributed objects right now:
> dealing with network disconnections.  Basically, *any* message might be
> remote (if you are using *transparent* remote objects), and so all of
> your code has to be paranoid if you are using remote objects.

Being paranoid doesn't seem like an ultimate solution to me :) One might
just as well argue that you need to be paranoid about errors in regular code
too, checking for every possible error condition every time you access a
file stream, or before every new you send, and so on. But this isn't
necessary most of the time; the cross-your-fingers approach gives you a lot
of mileage.

I can imagine something very simple, similar to the low-space notifier
window being put up by the remote invocation mechanism itself (ie. in the
neighborhood of the proxy class), with a retry button and all, when the
message send fails. If you want to get fancy, the notifier itself might
retry the message send at a certain interval, and go away and continue
quietly if it succeeds.

A strategically placed exception catcher or two in your own code would also
get you quite far, instead of coding error checks for every message send.

So I'd say it's not at all as bad as you put it.

> Alternatively, if you end up putting error-recovery code just around,
> say, canvas commands, then you are coding canvas-drawing specially.
...
> The overall goal of a big distributed network of objects is really
> beautiful.  
...
> Overall, it's neat stuff, but it still seems pretty theoretical.  I hope
> someone makes it really work someday!

Well, one has to start somewhere in any case. Making it work just for the
Canvas is a good starting point. The lessons learned will then allow you to
go further and make it more general. So writing special code for the canvas
is not a bad thing imo; it's a good start--especially if you are going to
write some display server code anyway: this has great potential for evolving
into something vastly more generally useful.

Henrik






More information about the Squeak-dev mailing list