From kde-core-devel Wed Sep 29 16:02:03 1999 From: Lotzi Boloni Date: Wed, 29 Sep 1999 16:02:03 +0000 To: kde-core-devel Subject: Proposal for this CORBA stuff X-MARC-Message: https://marc.info/?l=kde-core-devel&m=93862086506780 Just my 0.02c. I would do it as follows: 1. "Native embedded object": the canossa way. It is a shared lib and when it has the control it controls the UI, etc. Directly calls the widgets. Qt/KDE dependent. 2. "XML embedded object" There is a special type of native embedded object, which in it's turn embeddes or communicates with the real embedded object. Takes from it a description of the UI in XML and realizes it in the embedding frame. 3. "CORBA embedded object". It is again a special native embedded object, which serves as a CORBA client for embedded objects specified using IDL. I am not quite sure, but I think that one object of type 3 for all current style openparts would be enough, and a different one for Bonobo objects. So style 1 would be for fast, local components. Not network transparent. Style 2 & 3: network transparent, easy to connect to anything but slow(er). Comments? Lotzi On Wed, 29 Sep 1999, Lars Knoll wrote: > On Wed, 29 Sep 1999, David Faure wrote: > > > > > Yes I see :) > > > > > > > > I see that what we need is the best of both worlds : > > > > keeping CORBA interfaces for allowing third-party implementations > > > > but using shared libs for koffice, for performance and stability > > reasons. > > > > > > > > I can see two ways of doing this : > > > > 1) using the shared-lib functionality of Corba (hi Matthias !), > > > > 2) doing our own shared-lib stuff AND keeping IDL interfaces > > > > > > > > What IS bad is servers, we all agree on that (hopefully). > > > > So what need is shared libs. One way or the other among the two above, I > > > > think. > > > > > > I don't think (anymore..) that 1) is the way to go, as it > > > keeps us with the OpenPartsUI trouble. > > It's a trouble we have to live with if we want to remain open to > > other toolkits. I mean the real decision is there, isn't it ? > > Waldo, Jo (and Matthias?) say : let's keep that option open. > > Most others up to now say : we don't need that. > > I say, well I don't know, but sure openpartsui is trouble :) > > I think it would be nice to keep (possible) interoperability with > other toolkits. The problem is to find a way to do that without too much > overhead and bloat. The current openparts does for sure have problems > there. If we want to be able to interacts/embed only with other KDE apps, > we can use Canossa. It is for sure very nice, easy and fast. But we loose > the possibility to talk with programs written in other toolkits. > > On the other hand, if we want to keep open standards (which I would very > much like too see), we have to define these things in idl and use CORBA. I > don't really see an alternative to that. I would very much favor an open > approach. > > > As pointed out earlier on, it's not something we want NOW. > > But here the question is about the future... > > > > > I'm not sure I understand what you mean with 2) ? Using canossa while > > > keeping IDL interfaces? Which interfaces then? OpenPartsUI? > > That's what I meant yes. > > > > > I don't think that we should use a special solution only for > > > KOffice and let the other's use OpenParts. Or did I misunderstand you? > > You didn't misunderstand, but you put it in a strange way. > > It's very often that you see solutions for the general case with > > optimisations for the local case. CORBA does that for calls in the > > same process, Linux does it in a lot of places, ... > > I see no problem in providing an open solution with still having > > our own way of doing things. > > I would agree here. If both Components run on the same computer, one could > for example use shared mem to transport large chunks of data. If they use > the same toolkit, the need to do conversions for data types (e.g. Pixmaps) > will drop out. One could then just pass a pointer. All one needs is some > clever way of recognizing the other component's capabilities, and then use > the fastest possible way to communicate. > > > > I simply vote for 100% Canossa :-) > > Hmm yes we know :) > > But that's short term - we can find better long-term solutions IMHO. > > One more remark about speed: We shouldn't forget, that computers get > faster from day to day. This doesn't mean, we shouldn't try to make things > as fast as possible, but we will always loose some performance if we want > a general solution. But in the end it could turn out, that this > performance loss is not that important anymore, because the computers can > handle it easily. > > Cheers, > Lars > >