Lex Spoon wrote:
> 
> Marcel Weiher <marcel at metaobject.com> wrote:
> > Practically, I think it might be useful to build a remote messaging
> > system based on the assumption that it is the same and then see what
> > doesn't quite fit.  After that, (re-)introduce generic messaging to
> > cover the commonalities and handle the differences by specializing.
> >
> 
> Sure.  Just don't make the mistake that you can pick up any old object,
> move it across the network, and expect things to keep working.  For
> remote objects to work, the programmer will need to know which objects
> might be remote, and they'll have to add some code to deal with possible
> network failures.  Our goal should be to help with this process, not to
> try and make it disappear.
> 
> -Lex

I don't have an answers to this difficult question either.  Some degree
of automatic fault-tolerence through TupleSpaces might be interesting. 
There certainly seems to be some layering of services here which
parallels network protocol stacks.  Although incomplete, another
framework data point is the thread I started on ClientServer Framework
(or was that a discussion of language evolution?  ;-)  I shamelessly
used the promises and asynch correlation of requests/responses from your
RMI implementation, with some changes.  It doesn't actually work at the
moment but the structure of my distributed objects is discernable.

More importantly, there was recent comments about encoding in the VNC
thread with messaging between 2 Squeaks and, by extension, between 2
Smalltalks.   May I highly recommend that we work with the CampSmalltalk
project (which I was a small part of) to create a standard Smalltalk
Binary Encoding Stream.

As far as the layering goes...There are reliable network streams (with
exceptions thrown when appropriate), encoding of objects including
MessageSend which *is* supported by the Camp binary stream.  Above this
there would be the promise and correlation scheme, a nameservice, a
remote id table (for GC and handle management), and perhaps some
location transparency/fault tolerent services (with mobile
EvaluableActions).  I currently look to treat msgSends, exceptions,
events all separately.  My biggest headache is the same as has been
discussed here - how to decide whether to pass-by-value or
pass-by-reference.  It seems that this might be usage dependent...

I think that all of these layered protocol/reference services are hidden
behind the same proxy used in fencing sandboxes..

cheers and good day,
Rob

-- 
--------------------------------------------------
Smalltalking by choice.  Isn't it nice to have one!