Henrik Gedenryd <Henrik.Gedenryd at lucs.lu.se> wrote:
> 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 disagree.  Decent code should check for I/O errors.  It doesn't
necessarily check at every operation, but it at least has exceptions to
catch all possibilities.  In particular, network code quite *frequently*
has disconnection errors.  A server that doesn't handle this situation
is a poor server.



> 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.
> 

A fine strategy.  But you have to put the handlers somewhere.  Suppose
Morphic goes to redraw a window, the bounds rectangle for the window is
remote, and the network fails.  Now what?  How do you plan for stuff
like this?

I think the issue being missed here is whether the remote stuff should
be *transparent* or not.  I'm arguing that for the near future, you
really need to know which objects are local and which are remote.  And
as long as the programmer is keeping track of such things, it's not
really "transparent".  What would it take to make the remote-ness of
objects truly transparent?  I don't know.  It's an absolutely
fascinating question, but I've already got several taking up my time. 
:|

Luckily, there's a much more practical goal to go after in the meantime:
 making objects network with each other more easily.  How does one make
networking in OOP easier?  I know it was rather annoying to code up all
the serialization code I needed for the last two major networking
projects I worked on (MuSwiki and Nebraska).  Maybe a Remote Method
Invocation approach would have helped?  It's worth looking into, and
it's more likely to produce nearterm results.  It's also worth looking
into paradigms based on send/receive, though, since they are after all
closer to the semantics of normal networks.  Probably systems guys have
some good ideas about this stuff--it was in systems classes that I heard
of Remote Procedure Calls as something that's been studied thoroughly.

My beef is that, whatever toolkit we end up using, we not call it
"transparent" remote objects.  Let's not ever insist that the things
*look* like regular method invocations--after all, they aren't! 
Instead, let's do whatever turns out to be the most useful thing.



-Lex