From kde-core-devel Tue Sep 14 20:15:32 1999 From: Simon Hausmann Date: Tue, 14 Sep 1999 20:15:32 +0000 To: kde-core-devel Subject: the MICO/CORBA issue. X-MARC-Message: https://marc.info/?l=kde-core-devel&m=93734188322527 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 ;-))