Hi Monty,

I'd like to reply to your article at
http://www.osopinion.com/Opinions/MontyManley/MontyManley13.html

I think for a deep discussion about this topic we have to distinguish the
kinds of components and the type of communication between them.

Depending on this it makes sense to use different technologies for components,
each addressing the specific requirements.

In KDE it looks like this:

1) Whenever a performant and lightweight communication is required,
   shared library components, languange dependend and toolkit dependend,
   are chosen (in KDE). This provides a maximum of performance while
   eating as few resources as possible, and in addition it provides an
   _extremly_ powerful object model. An object model every average KDE/Qt
   developer is already familar with! The Qt object model. This means people
   don't have to learn yet another big technology (like CORBA in fact is, and
   CORBA is complicated) in order to make their hacked-in-their-free-time-
   small-application communicate with other components on the desktop.

   A classical examples here are:
     - embedding an image viewer component into a browser shell
     - an image editing plugin which applies a special
       mathematical-O-difficult algorithm on a 16MB RGBA image.

   For these examples performance and resources are more important than
   stuff like network transparency. Noone is going to embed a remote
   spreadsheet document into a word document, running on a machine on
   the other side of the ocean. This is a nice dream and it is certainly
   technically interesting (no doubt about that), but it is not what
   the average desktop user really wants. The priorities are different here.

2) Another kind of components are, well, applications as-is. Think of the
   following example: You have a text editor application open somewhere,
   you click on a text document in your file browser and you want to re-use
   the existing text editor application instance to open up the document in
   a new window. (instead of starting yet another process) . So you want a
   simple network transparent architecture which allows you to say something like
   "Application ABC sends a message to object DocumentFactory in Application CDE
    to open up the document at http://www.blah.org/docs/foo.txt" in a new window"

   Another example is scripting. But well, let me paste a few lines of example
   code, which speaks for itself:

   (python)
   from dcop import *

   app = DCOPApplication( "kspread" )

   documents = app.KSpreadIface.documents()

   doc = documents[0]

   table = doc.map().table( "Table1" );

   cell = table.cell( 10, 20 );

   cell.setText( table.cell( 2, 1 ).text() + " Blah" );

   (note that this is a real-life, working example)

   Here language independence and network transparency have priority, no doubt.
   And that's why KDE uses DCOP (based on the standard ICE library) . DCOP is
   easy to learn (for example human readable object names in contrast to
   unreadable CORBA IORs) and is extremely lightweight (have a look at the library
   size and the memory consumption) . (not to mention that the protocol is far less
   complex than IIOP and supports sugar like signals and slots :-)

>In the Windows world, COM is the standards-bearer; in the Unix world,
>CORBA carries the flag.

In the Windows world Microsoft defined COM as standard. Who/Which/What defined
CORBA as "standard" in the Unix world?

I believe that there is not standard, yet. (standard in the meaning that really
a lot of software components are based on it)

>The KDE developers experimented with CORBA (KOM) early in the project, but
>eventually discarded it due to speed problems and the complexity of the code.
>Instead they settled on a "home-grown" solution called KParts. Conceptually
>KParts is similar to Microsoft's COM, but it has some significant limitations
>which are delineated below:
>
>KParts is C++-only. This breaks the "language-independent" aspect of component
>programming.

The DCOP protocol is open and languange/architecture independend.

>KParts cannot communicate "over the wire" (e.g., it has no RPC mechanism).
>This breaks the machine-neutral aspect of component programming.

DCOP is based on ICE, which is network transparent.

>KParts is specific to KDE (i.e., you cannot use KParts to write a GNOME
>component).

There exist (yet unreleased) DCOP bindings for C. (I'm still in the process
of cleaning up and fixing some last issues) . I hacked up a small example
which does exactly what you are talking about: It uses DCOP to embed a small
GTK application into a KDE shell. And yes, it works "over the wire" :-)

(This however is unreleased stuff. Please drop me a private mail if you are
interested. Then I can send you the tarballs)

>KParts components cannot (natively) communicate with COM/CORBA components, or
>vice-versa. KParts is thus entirely self-referential and enclosed.

Please take into account that KParts is one specialized component architecture in KDE
and that DCOP is a second one, developed to address the above mentioned points in fact
(languange independence, network transparency) .

We simply make a distinction, depending on what components are needed on the desktop.

Thanks for listening :-)

Bye,
 Simon

P.S.: Please note that this is only my personal humble view/opinion