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

List:       kde-core-devel
Subject:    Re: the MICO/CORBA issue.
From:       Matthias Elter <me () main-echo ! net>
Date:       1999-09-17 19:36:00
[Download RAW message or body]

Am Fre, 17 Sep 1999 schrieb Lars Knoll:
(...)
> This also sounds like the best way too me. There are some things I don't
> like about the shared lib approach:
> 
> First of all, some buggy component can easily bring the program down.
> Using CORBA, you at least _have_ the possibility of catching the
> exceptions and making the code fault tolerant.
>
> The other thing I like about CORBA is the network transparency. With
> shared libs, we would loose this option. Right, it's not used at the
> moment, but it might be in the future. X is network transparent, and
> although I don't use this feature on my machine at home, I use it every
> day at work. Can we really exclude, that the same might apply to
> components some time in the future?

We don't lose network transparency as the proposal was not about dropping
CORBA, it was about using CORBA _but_ to acess the objcets using the BOA through
shared libs. With the proposed component server you still have network
transparency when needed.

> Alltogether, I would prefer staying with CORBA, but to move to some Qt
> bindings. They would save us a lot of overhead (e.g. Qt <--> CORBA
> conversions), make the code easier to read, and programming a component
> perhaps almost as easy as developing a regular Qt app.

Yes, Qt/KDE<->IDL bindings would be very nice for better integration/ easier
developement and improved compile times (using QTL insated of STL).

Greetings, Matthias

--
Matthias Elter
me@kde.org / me@main-echo.net
KDE developer

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