On Tue, 22 Jun 1999 21:29:55 +0200, Stefan Matthias Aust wrote:

>Hi!
>
>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 extremly inefficient. 
>
>Here's a very informal analysis:
>
>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 #encodedName method, which adds a $_ to
>the proxy name, creating a new symbol then, just to remove the $_ again in
>ORBServer>>evalute:, seems to be a performance bottleneck.
>
>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.
>
>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.


Please, no polling.  Events or messages should be used wherever you can.

Terry Raymond
Crafted Smalltalk
(401) 846-6573    http://www.craftedsmalltalk.com