Robert Maldon <[EMAIL PROTECTED]> wrote:
>
> On Wed, 9 Feb 100, Goblin wrote:
>
> > This is one of the main complaints about MICO. It relies heavily on
> > templates and can be a bitch to compile. It was designed as a teaching
> > aid rather than for efficiency and performance was a bit of a problem
> > too. I have heard that improvements have been made to the performance
> > recently. I believe that MICO has been adopted by KDE for desktop
> > interprocess comms (ala OLE/ActiveX/COM).
>
> I remeber seeing on the web that KDE were thinking of abandoning their use
> of
> CORBA in KDE 2.x. There were a lot of stability and scalability issues they
> were having with MICO, not necessarily CORBA.
I know that the KDE team were looking at using their own non-standard
C/C++ mapping to the ORB. ie still using IIOP for the protocol but with
a cut-down interface. I would not be surprised if they had chucked it
out altogether at this point.
> TAO makes me a bit nervous. It is the product of a Washington Uni group who
> do research into real-time extensions to CORBA. Each release seems to
> involve lots of internal changes and produces a similiar sized bug list.
> ACE is pretty good for those who want free C++ classes to do things like
> threads, collections (maps, bags), strings, etc.
>
> omniORB, however, is very solid and fast (but has poor doco) - highly
> recommended.
This brings me to a problem that causes me a great deal of angst. I
would really like to contribute to an OpenSourced ORB, but I keep
dithering from one to the other, unable to make a decision on technical
grounds and unable to see a clear leader emerging on pragmatic grounds.
* MICO is widely considered to be a hog to compile and sluggish to run
KDE seem to be having a lot of trouble with it, which doesn't bode
well
* Orbit is written in C (I have written my share of C code, but I much
prefer to work in C++)
* OmniORB looks good, but it is definitely "Cathedral" rather than
"Bazaar". I subscribed to the mailing list for a while and almost
all the developers have AT&T email addresses
* TAO is frighteningly monolithic. Also it has a BSD-style licence
rather than GPL, which I regard with some suspicion
Meanwhile, I am using ORBacus (http://www.ooc.com) at the moment. If anyone
is interested in investigating CORBA I highly recommend this product as
being one of the best on the market. Tight code, very stable, excellent
conformance to the latest standards, amazing support. Unfortunately not
OpenSource (tm) but souce-code-provided and free for non-commercial use.
Lots of good demos to give you examples of just about every CORBA feature.
ORBacus comes in C++ and Java flavours. Linux support is very good since
this is their primary development platform.
Alternatively, go with OmniORB. As Robert says, documentation is not
great, but there was an intro tutorial in Linux Journal last year
(October?) which walked you through a simple hello world.
> CORBA has been around for about eight years now, but for real-time systems
> people like myself I still think it lacks some all important enterprise
> features. These issuses are slowly being addressed. Glueing together
> disparete
> languages and systems, however, is very attractive.
In the early days the CORBA focus was on pulling legacy systems into
the client/server world. The benefits were pretty obvious and there was
lots of money for this, so CORBA really took off. The platform/language
independence was critical for this and works very well.
These days we are looking more at what I would call "distributed" systems
- peer-to-peer systems where processes are both client and server and
CORBA is an integral aspect of the design process. This is what interests
me.
The realtime stuff is pretty cutting edge for CORBA. I don't think it
was really designed for this, but obviously there is the potential for
really interesting work to come out of it. As Robert says, there are
some important features missing, but then what are the alternatives?
Do it yourself or use some proprietory middleware I guess.
-------------------------------------------------------------------------
goblin
--
SLUG - Sydney Linux Users Group Mailing List - http://www.slug.org.au
To unsubscribe send email to [EMAIL PROTECTED] with
unsubscribe in the text
