ORBit status?

[David Wragg <dpw doc ic ac uk>]

Hi,

Several weeks ago, I mentioned that I would be interested in working
on ORBit. Well, I'm now able to follow up. I have a few questions
about the status of ORBit, then below I discuss features I'd like to
see.

I've got the latest ORBit sources from CVS, and to say the least it
looks preliminary, and I don't see much sign of active development. Is
anyone currently doing work on it? As it stands, is anyone committed
to working on it in the future? If it is ever to be used in Gnome it
needs turning into something that other people can at least play with.

If I was develop it, I'd pretty much be starting from scratch (though
of course looking carefully through what's already there for
inspiration). So before I make a decision to do this, I need to know
what other people's opinions are on the subject, and make sure I'm not
treading on anyone's toes.


Now for more generally comments: There are at least three good free
C++ CORBA ORBs out there. Yet when I've played with these I've always
ended up feeling that they focus tightly on implementing the C++
bindings and IIOP, to the exclusion of everything else. A free
distributed object infrastructure would be a great thing - naturally
it should be based on CORBA, but just as importantly it should allow
free software authors to build distributed applications and components
with a minimum of fuss.

It may sound as if I'm proposing writing something like COM/OLE2 or
SOM, and in many ways I am. In fact, any CORBA ORB which allows object
implementations to reside in shared libraries in effect defines a
component object standard, so we might as well do it rigorously and
language independently. Also, basing it on CORBA from the start will
save a lot of effort compared to SOM/COM. (COM isn't really as
complicated as it is often made out to be - it just seems like it
because all of the documentation for it is mind-numbingly verbose and
short on technical details).


Anyway, enough of the screed, here are the features that, for me,
would make it worth developing ORBit:

- A robust binary interface specification for object implementations
contained in shared libraries. A kind of in-process equivalent to
GIOP/IIOP.

- Given the above, a client stub can just be a shared library
containing an object implementation which happens to convert method
calls into on-the-wire GIOP requests, just as DCOM/DSOM do it.

- Allowing easy integration into existing apps, both for client and
server operation.

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

- Extended language bindings for C. The CORBA C language binding is
pretty awful, compared to Gtk-style object-oriented C. I think it's
possible to keep compatibility with the CORBA C bindings while
incorporating something very similar to the Gtk style.

- Bindings for other languages (C++ and Guile spring to mind).

- Implementations of the various services.

Comments welcome.

--
Dave Wragg.