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

List:       kde-core-devel
Subject:    Re: the MICO/CORBA issue.
From:       Sven Radej <sven () lisa ! exp ! univie ! ac ! at>
Date:       1999-09-15 11:52:34
[Download RAW message or body]

On Tue, 14 Sep 1999, Dirk A. Mueller wrote:
>Simon Hausmann <shaus@neuro2.med.uni-magdeburg.de> wrote:
>
>> speed. CORBA based plugins, with the plugins "sitting" in separated
>> process, would just result in a performance problem.
(...)
>> Components are small encapsulated pieces of software, and separating
>> them in shlibs represents the idea of a component based environment.
>
>does that mean that a program using a component will use the CORBA
>stuff to find out which thing to load and then dlopen() it and
>communicates with it directly, bypassing the overhead caused by CORBA?
>
>That would be
>
>GRRRRRRRRRRRREEEEEEEEEEEEEEEEEEEEEEEEEAAAAAAAAAAAAAAAATTT!!!
>
>
>But this leads to more problems:
>
>- re-entrant safety ?
>- how do the components communicate which each other when they live in
>different processes?
And portability? Do all our target platforms have dlopen?
Does it mean that every kde-app should split in two: executable (just loader)
and shlib (the true code)? I don't like it somehow.
Doesn't ELF mean Execute and Link Format? Can't we on demand link against an
executable? Example: konqy wants to show an image, dlopens kview and uses
kview's view only - or even some tool/menu items? How is that supported on
various platforms?

-- 
Sven Radej      radej@kde.org
KDE developer   Visit http://www.kde.org

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