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

List:       kde-core-devel
Subject:    RE: back to corba (was RE: Transparency -- take 2)
From:       Lars Knoll <Lars.Knoll () mpi-hd ! mpg ! de>
Date:       1999-09-29 15:33:14
[Download RAW message or body]

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]