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

List:       kde-core-devel
Subject:    the MICO/CORBA issue.
From:       Simon Hausmann <shaus () uermel ! Med ! Uni-Magdeburg ! DE>
Date:       1999-09-14 20:15:32
[Download RAW message or body]

Hi,

Currently many people are unhappy about MICO and/or CORBA in general, some
even hate it/both ;-)
(*excluding* me)

We discussed a lot on IRC lately about this.

Another separate discussion was about plugins for KImageShop. The major reason
why Matthias Elter wanted them to be contained in shared libs was speed.
CORBA based plugins, with the plugins "sitting" in separated process, would just
result in a performance problem.

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

And this was the key which made him suddenly wake up in the middle of the
night (as he told us :) , bringing up the following proposal:

The whole component technology in KDE should be based on shared libs. Components
are small encapsulated pieces of software, and separating them in shlibs
represents the idea of a component based environment.

AFAIK COM, Star Office and Mozilla implement components exactly like this, via
shared libraries, not via separate processes.

So for example all KOffice document and view implementations would be shlibs.
(just think of libkword.so ;-)

Quite the same with Konqueror: The mainview and its builtin view components.

The reason for this trouble?
- performance/speed
- design

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.

This is what Matthias is proposing, and IMHO it is an exciting proposal :-)

My personal comment:

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

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.

Now: What do you think of this? 

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

Greetings,
 Simon

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
      - a marshalling system
      and drop MICO completely

      ;-))

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