Hmmmm, the shown arguments *against* the shlib approach which impressed me
most and which make me think that we should re-think it are the
KApplication and the i18n issue. This are *very* strong arguments IMHO.

So perhaps we should keep the current layer (components on a per-process
basis) and dive one layer deeper, the ORB:

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?

Ciao,
 Simon