Stefan,

First of all, thanks a lot for looking into this in so much detail!

>Last weekend, I looked into the fly-by-wire ORB code and franky, I was a
>bit disapointed.  It's written in a way I wouldn't do such a thing (a
>questionable design IMHO) and the whole concept is extremely inefficient.


Hopefully you now have the modified connections.cs framework that I posted.
This should be a little closer to what we are trying to achieve. I agree
that it's still a long way from being an ORB, but we need to start
somewhere. At this stage the socket connection works,  you can create remote
objects and send messages to them via a remoteProxy.  The remote object also
sends back return values (objects) via the ORB.

>The RemoteObject class should be a real proxy thing.  Instances of
>RemoteObject should behave exactly as the original object they represent.
>Therefore, it must not implement #class.  It should have no methods that
>might shadow original methods, for example #session.  Of course, debugging
>support could be an exception.

The way to go is to subclass RemoteProxy from nil, but not now. Subclass it
from Object for debugging purposes.

>RemoteObjects know a session (actually an ORBClient instance) and have a
>(hopefully unique) name.  No proxy can't be without a name.  The proxy's
>#doesNotUnderstand: method forwards any messages sent to the proxy to the
>session which in turn will forward the message send, encoded as BOSS
>(VisualWork's binary object storage format), to the ORBServer instance.


Speaking of performance bottlenecks, someone on comp.lang.smalltalk gave me
an excellent hint. Everytime the Proxy goes through doesNotUnderstand:,
it builds the method it does not understand. It will then implement the
forwarding code directly the next time the method is called. This should
save heaps of method lookup time. (Is there any other language that can
dream of doing such things? - only in Smalltalk).

>However, I don't undestand why both client and server will communicate in a
>pseudo-asynchron manner.  All communication happens in new forked processes
>using thread-unsafe queues which are then polled.


Using lots of forked processes is a sure way to run into bugs early. The
current version uses blocking calls for now.

>The classes ORBConsole, ORBDialog and ORBWorkspace are just for the GUI
>- which is unfortunately tightly bound to the rest of the ORB code.
>However, the GUI looks really nice (I tried the code on VisualWorks).
>IndexedQueue and StringBOSS are helper classes.  ORBRemoteInterface offers
>a restricted interface to class ORB which can be accessed remotely.


I ran it in VW too, which gave me the inspiration. The UI is nice, but right
now I can see everything I need to see just with inpectors on the ORB and
the Proxy. As an experiment, I created a remoteProxy that represented the
Sensor in another concurrent image. By saying Sensor := remoteProxy I was
then able to click in one Image but drag windows around in the other image.
(Not terribly useful I know, but I got a kick out of it).

>So here is my sketch of an ORB; you could actually call this lightweight
RMI
>(remote method invocation), as the idea is similar to the Java solution:
>
>Each image has an ORB which can contact ORBs of other images using a direct
>socket connection.  An ORB is identified by a host name and port number
pair.
>
>Each ORB keeps track of all objects which are known by other images. These
>are the owned objects.  It also keeps track of all proxies (or stub or
>shadow or remote objects) which exist for other images' objects.  (Let's
>ignore distributed garbage collection for now.)
>
>A proxy knows its UID and the image's orb. It is implemented as an object
>without a superclass which understands just the bare minimum of messages
>and forwards all unknown messages via its orb to the real object.  This
>should be completely transparent to the user.


Agreed - the transparency is essential.

>The server will lookup the receiver object using the OID and will then
>perform the selector. Argument data are copied by value for "primitive"
>data like numbers, strings or symbols.
>For the binary encoding we need a simple encoding for all primitive
>types and arrays. We also need an encoding for proxies and remote calls.
>This encoding is much simpler than any existing BOSS or ReferenceStream
>system. (Optionally, complex objects could be copied by value, but that's
an
>extension.)

I have just used ReferenceStream at present. How would you deal with things
like Dictionaries being returned from method calls?

>In the meantime, I started to implement this idea - first in Squeak but
>when I noticed that using Sockets wasn't as simple as I hoped, I finished
>it in Java.

Go back to Squeak, the connections stuff takes care of all the socket
details, including default time outs.

PS I have set up a new project page on the Swiki for this stuff. Please put
up links to any relevant code there. (The link is broken, but I will fix it
soon)

Thanks again  - this is excellent.