Re: ORBit (was Re: * mico)

[Owen Taylor <owt1 cornell edu>]

Elliot Lee <sopwith@cuc.edu> writes:

> On Thu, 19 Feb 1998, Jason Gilbert wrote:
> 
> > I only had a few added requirements: 
> > multithreaded
> 
> Why? We can do it without threads, and threads are not very portable in
> the grand scheme of things. Threaded programming also adds a whole new
> level of complexity, and I'd like to make as simple an ORB as possible,
> not a complex one ;-)
> 
> (Simple means easy-to-read code & a straightforward design, not "lacking
> in features").

I think I'm on the side of threads. Not that threads are essential
to the type of GUI applications that we are doing, but if you want
to do heavy duty servers in CORBA, they make things a lot easier.
(An ORB inherently has a lot of state, so forking off processes
to handle new connections may not work well.)

If you are serious about this project, I think the guiding maxim
has to be "The world does not need yet another ORB". There are
a lot of ORB's out there - none of them completely satisfactory.
There is no need for another "not quite good enough" ORB. 

I'm not saying that it should be all things to all people - but
the basics should be there. And threading is something that is
quite hard to retrofit in after the fact and get good performance.

I said, "I think", at the top, because threading does provide
challenges. Writing a system that is threaded from the ground
up doesn't add all that much bloat, though it does add a certain
amount of complexity. 

Writing a system that can be either threaded or non-threaded, though,
and especially one that supports multiple threading API's makes for a
ugly system. One of the biggest problems is that threaded and
non-threaded ORB's go about things in different ways. If a connection
needs to be watched, a threaded ORB may simply spawn off a new thread;
a non-threaded ORB will do the equivalent of a gdk_input_add.

One approach would simply to require a working pthread library.
That definitely is the wave of the future - in a few years it
won't be a problem. But it will be a problem in the immediate
future. In any case, I would advise _thinking_ about threading
when designing the ORB. Avoid global data like the plague; use
fine grained "objects", etc. 

> > and java language bindings.
> 
> We will try to make it easy to do bindings for any language, but I must
> point out that there are some good Java ORB's out there already (IIRC, 
> http://www.linas.org/linux/corba.html had a list).
> 
> > I would also like to see an Event Service modeled after the RT Event
> > Service available w/ the TAO ORB or maybe an implementation of the
> > Notification Service which is still in the RFP stage at the OMG.
> 
> This can be an add-on. I do *not* relish the though of yet another big &
> bloated program ;-) Making it easy to put add-ons into the thing (perhaps
> the way glibc does) would be a definite goal. 

I think lean mean core + add-ons is very much the way to go. But
I also tend to think that we should struggle on with MICO + hacks
for a while. There is plenty of other work to do right now, and
I don't think any of us has the experience to predict where the
bottlenecks in the design are. 

I certainly don't have the time to do more than spectate on such
a project right now. 

I would also advise taking a good long look at how the ILU
kernel is set up and the documentation about to write a new
language runtime. There is a lot of cruft, and extraneous
stuff there, but fundementally it is a good sound modular 
design. 

Regards,
                                        Owen