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

List:       kde-devel
Subject:    Re: CORBA on kde-core-devel
From:       Simon Hausmann <shaus () uermel ! med ! Uni-Magdeburg ! DE>
Date:       1999-09-17 14:59:38
[Download RAW message or body]



On Fri, 17 Sep 1999, Bavo De Ridder wrote:

> 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 !

What - in your opinion - we should use as alternative solution then? (on
the long run)


Ciao,
 Simon

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