From kde-core-devel  Fri Sep 17 19:36:52 1999
From: Lars Knoll <Lars.Knoll () mpi-hd ! mpg ! de>
Date: Fri, 17 Sep 1999 19:36:52 +0000
To: kde-core-devel
Subject: Re: the MICO/CORBA issue.
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=93759666128929

On Fri, 17 Sep 1999, Harri Porten wrote:

> Simon Hausmann wrote:
> > 
> > Perhaps we should concentrate on what Torben once mentioned: Invest time
> > in hacking the IDL compiler and our own (de)marshalling code, in order to
> > be able to
> >  a) create smart stub/skeleton code (optimised for the qt/kde framework!)
> >  b) use qtl where possible
> >  c) have qt/kde bindings. this would have the outrageous advantage that
> >     programming with CORBA becomes *much* easier, as developers won't have
> >     to deal with the MICO/CORBA types (sequence, CORBA::WChar*, etc.) but
> >     can stay with the existing ones.
> > 
> > What do you think?
> 
> This way sounds very promising to me, too. A seamless and therefore
> _light_ integration could eliminate some of the current problems.

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?

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.

Cheers,
Lars