Re: ORBit status?

[David Wragg <dpw doc ic ac uk>]

Tom Tromey writes:
 > David> If I was develop it, I'd pretty much be starting from scratch
 > David> (though of course looking carefully through what's already
 > David> there for inspiration).
 > 
 > Is there something wrong with ORBit as it now stands?

As I said, it's obviously in a very preliminary stage of
development. I couldn't tell whether the project was alive or not (not
for lack of trying, but I'm a CVS newbie). My worry is that because it
will take a lot of work to get ORBit usable, and because it will never
be as visible as other parts of GNOME, that it will get left on the
sidelines, and MICO will get used instead because it already works
well.

However, if someone is happily working on it, please consider my
original post as suggestions, and tell me how I can help out (or where
I can get off :-).

 > 
 > 
 > David> - Given the above, a client stub can just be a shared library
 > David> containing an object implementation which happens to convert
 > David> method calls into on-the-wire GIOP requests, just as DCOM/DSOM
 > David> do it.
 > 
 > I think this is part of the current ORBit plan.  See the file
 > `ORBit/docs/IDEA1' (which explains the idea, but just barely).

Ah, I see now. Yes, it clearly does mean that.

There are many details to a binary interface standard though. I'll
discuss this point (it is vital) somewhere else though, because this
message will be long enough without it.

 > 
 > David> - Support for asynchronous object requests, i.e. the out
 > David> parameters and return value of a method call get passed to the
 > David> client using a callback. Anyone who's seen graphical programs
 > David> freeze while they use the Unix DNS interface will appreciate
 > David> why this is useful. Threading is in many ways the preferred
 > David> approach, but an event-based approach can fit more cleanly into
 > David> existing single-threaded programs.
 > 
 > The approach ILU takes is to reenter the event loop while waiting for
 > a return value.

There are difficulties with that approach if an ORB is both sending
and recieving requests. What happens if while waiting in the event
loop it recieves a request, and the object implementation servicing
that request issues another request. It gets horribly tangled.

Maybe authors doing things like that, but not using threads, deserve
what they get.

 > The callback model doesn't gain you anything over
 > this, unless you don't want the ORB to know about the event loop.  I
 > think it is easier and cleaner to each the ORB implementation about
 > event loops than it is to write apps in a strange style.

Of course the synchronous language bindings must be included, for
CORBA compliance. 

Having the ORB know about the event loop sorts out simple cases (such
as the DNS analogy above, that was a bit of a straw man), but things
get tangled if you want a program which sends and recieves
requests. If the answer is "just use threads", my question 

Why do I consider this important? Because a couple of years ago I was
writing applications where these kinds of tricky situations arose, and
I was unable to use (for instance) ILU for just this reason, so I had
to roll my own solution. It has graphical (Tcl/Tk) based programs
sending and recieving thousands of requests per second, and in those
days was running on 486s and early Pentiums. Under those conditions
the threaded approach has huge overheads compared to an event-based
approach.

So I do think this merits consideration, and if the general conclusion
is "use threads" then at least a decision has been made up front,
rather than not because the alternatives haven't been considered.

Of course, I'm only making a fuss over it because I think I can
implement it without any drawbacks for people who are only interested
in the conventional synchronous language bindings. But it would be
tremendously difficult to hack this feature into ORBit once it is in a
semi-completed state. Plus of course because I really want to port the
programs I've mentioned to GNOME/Gtk/Scheme/ORBit :-)

--
Dave Wragg