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

List:       kde-core-devel
Subject:    Proposal for this CORBA stuff
From:       Lotzi Boloni <boloni () cs ! purdue ! edu>
Date:       1999-09-29 16:02:03
[Download RAW message or body]


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

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