[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    CORBA on kde-core-devel
From:       Bavo De Ridder <bavo () cs ! kuleuven ! ac ! be>
Date:       1999-09-17 14:56:19
[Download RAW message or body]

Hello,

I just read the CORBA thread on kde-core-devel. I was really surprised
after reading the thread !

First let me briefly repeat what the thread said:

They suggest using shared libs when opening components in KDE. There is
actually no need for remote CORBA capabilities for a component when it is
used in one application at a time. The only, rare, exceptions is when a
component is only available on a remote computer. Removing CORBA entirely
is not such a good idea for the following reasons:

 - we loose the benefits of IDL files. In the future components could be
   used from perl, python, ...
 - remote components should still be supported

Why was i surprised while reading this? It seems the KDE is evolving to
what Microsoft already has for several years: COM!

COM was designed to let developers load shared libraries with component
code and a specified interface (Microsoft IDL) thus enabling the
development of components in another language then the one used in the
hst application. After a while Microsoft developers saw that with a 
little hacking they could extend COM with remote capabilities. They just
inserted stub/skeleton/proxy code in the library -> DCOM.

CORBA was designed for remote components. CORBA is definetely not the best
tool for dynamic linking with components. Although it can do the job, it
is clearly overkill (and a lot of that !).

COM was designed as a standard for calling functions in shared libraries,
the developer only knows the interface of the component. That is why you
can exchange pointers in COM, in the first days nobody thought about
remote components (components in another address space or even another
computer). Now COM (DCOM) is not the best tool for distributed components
(it has to have marshaling code for pointers, ....). Microsoft however
encourages the use of DCOM over COM for the very simple reason that DCOM
offers you more stable programs (a crashing COM extention of IIS won't
bring down IIS as a whole).

COM and CORBA are each extreme examples of interface based calling
mechanisms. COM meant for pure in-process components and CORBA for pure
out-of-process components. What we need is something in the middle ...

We can only hope that CORBA + in-process loading (the shared library BOA
invocation mode) is just that in-the-middle solution !


BDR

[prev in list] [next in list] [prev in thread] [next in thread]