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

List:       kde-core-devel
Subject:    Re: the MICO/CORBA issue.
From:       Steffen Hansen <stefh () mip ! sdu ! dk>
Date:       1999-09-14 21:49:55
[Download RAW message or body]

On Tue, 14 Sep 1999, Simon Hausmann wrote:

> Now recently I told Matthias about the fact that MICO's BOA is able to load
> CORBA objects from shared libs.

The shlib code could maybe be lifted from BOA and used in the POA also.
 
> What remains is the question of network interoperability. The average user
> probably won't deal much with this, but killing this feature is surely the 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.

The normal way seems to be to load the object into the address space of
the requesting process, and not into kded. Why change that?

(ok, i see the problem with a remote kded and a component that is not
available locally)
 
> Together with tinyMico this could be a real alternative to the current
> situation. 

And last but not least a gcc-3.0/libstdc++ that is less stupid
about templates.
 
> 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 find the time i'll help. But i just started on my new job, and i'm
busy like hell (today i got home from work at 22:30). We have a deadline
very soon, and hope it quiets down after that.

BTW: Did my questions about kcmkded and .desktop files reach the list? I
didn't get a single answer.

greetings,
-- 
Steffen Hansen                            
email: hansen@dexel.dk, hansen@kde.org 

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