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

List:       kde-core-devel
Subject:    Re: the MICO/CORBA issue.
From:       "Dirk A. Mueller" <dmuell () gmx ! net>
Date:       1999-09-14 21:39:40
[Download RAW message or body]

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.

Yeah. You can watch that now by dragging another window over
Konqueror's view. The dragging there is 2x-3x times slower than over
other windows...

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

> wrong thing. So the solution is quite simple: Provide a kind of
> component server (kded?), loading the components dynamically on
> request and forking into a separate process then (to avoid one
> crashing component to crash the whole component server) , serving them
> via IIOP.

Although I don't know how it works, it sounds very cool :)

> Together with tinyMico this could be a real alternative to the current
> situation.

right!

> I like it, and I'd be willing to spend my free time helping with the
> "big conversion" and helping rewriting kded, if we decide going for
> it.

If I knew more about all that stuff, I'd really like to help..

> If we all want to do this step, then we have to decide *real soon*
> (and we have to extend the schedule - hi Waldo :)

Big yes from me if above assumptions are right :)

> P.S.: If we really want to be crazy, then we take our time at KDE II
> and      - write an idl-to-qt-kde-bindings compiler

I've never understood why we don't drop that STL stuff  anyway ;)

>       - a marshalling system
>       and drop MICO completely
>; -))

If we can get a smaller ORB that works for our purposes, we should go
for it (tinymico, etc).


-- 
Dirk A. Mueller

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