Re: Ditching CORBA, again?

[Cristian Tibirna <ctibirna total net>]

On Sun, 10 Oct 1999, Dan Kegel wrote:

> http://linuxtoday.com/stories/10975.html says:
> >Torben Weis, the chief architect for the KDE Object Model 
> >(KOM) and OpenParts, announced the "new and improved"
> >next generation OpenParts. The new approach to application or 
> >component embedding, code named "Kanossa", uses
> >shared libraries rather than CORBA.
> 
> And:
> >Matthias Ettrich and Preston Brown also worked feverishly 
> >through the weekend to develop a lightweight message based
> >IPC/RPC mechanism for KDE -- one that can be used in addition 
> >to the powerful KOM. The result was the Desktop
> >Communication Protocol (DCOP), based on the X11R6 standard 
> >library LibICE. ...
> >Initial benchmarks seem to indicate that DCOP will be a hit. 
> >Comparisons between DCOP and MICO show an improvement of 40 - 100% 
> >for speed and over 50% for memory. One test of 10,000 synchronous 
> >RPC calls between distributed objects took 4.5 seconds in DCOP 
> >and over 8 seconds using MICO. 
> 
> It certainly sounds like KDE is abandoning CORBA, contrary to
> what was posted here recently.
> Somebody in the know at KDE please clarify.
> - Dan

Yes, it may sound if you want it to, but it's certainly not true. Look at
the mailing lists at http://lists.kde.org (especially kde-core-devel).

Just one week ago the CORBA team improved the CORBA usage by creating
cuteIDL, a set of IDL specifications adapted to and optimized for MICO use
in the KOM model.

It was, nevertheless determined undoubtly (and there are nice pieces of
litterature circulating among us in support of this) that CORBA will
always impose an unnecessary penalty on performance when used for
interapplication communication (and component embedding) inside the same
physical computer. 

Hence, after long debating and argumentation, supported
with strong demonstration arguments, it was decided that for IPC/COM
inside the same computer, shared libs are much more appropriate. \

Kanossa, which only replaces the old OpenParts (but lets untouched KOM)
does exactly this: implements shlibs for component embedding. The results
are already astonishing, as Kurt's article says.

Once the things with Kanossa settle down (surely long before KDE-2 being
released) wrappers will be built for Kanossa (based on MICO and cuteIDL)
that will allow using of kanossa parts over CORBA (hence allowing
general scripting and network transparency). 

It is to be noted that Kanossa makes heavy use of XML in order to publish
GUI interfaces. This has the well know advantages. Also, it's extremely
fast, very flexible and unspeakably stabler.

As about DCOP, this was a long postponed essential need for KDE. Right now
almost each and every application has to develop its own IPC methodology
using X atoms or whatelse. This had deridable limitations and could become
quite difficult to develop with or maintain. DCOP is an alternative IPC
mechanism, which will be used for *shouldering* (and not replacing it)  
CORBA there where speed and reduced memory usage is highly needed. DCOP
will allow for easier implementation of applets (not only for panel but
also for desktop, window manager, control center and whatnot).

CORBA stays there, nice and beautiful, with KDE. It's just that just
overhyped words will never be able to make users overlook performance
penalties or instability. There where scripting, network transparency and
other CORBA specialties will be required, CORBA will still be used.

In fact, these don't even have to be advocated. KDE people are known for
their way of acting: "reuse proven, existent tools", "it has to work now".

Cristian

--
Cristian Tibirna     : ctibirna@total.net     : www.total.net/~ctibirna
PhD Student          : ctibirna@gch.ulaval.ca : web.gch.ulaval.ca/~ctibirna
KDE contact - Canada :  tibirna@kde.org       : www.kde.org