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

List:       kde-core-devel
Subject:    Re: A new framework for embedding ... without CORBA
From:       Simon Hausmann <shaus () uermel ! Med ! Uni-Magdeburg ! DE>
Date:       1999-09-30 6:56:51
[Download RAW message or body]



On Wed, 29 Sep 1999, Dirk A. Mueller wrote:

> > So this is no removal of an open desktop component standard IMHO, the
> > idea of components remains! It's just a matter of using fast and
> > efficient C++ interfaces
> 
> First: Anything that improves the current (lack of) performance should
> be STRONGLY considered. It doesn't care if we're using a fancy internal
> structure and can communicate with the rest of the world if it is so
> slow that noone will use it. Remember, there were enough guys who
> whined that KDE 1.x had too much bloat...

I agree :-)
 
> - it likes to kill cross-language operation. Most other than C++
> programmers won't have it easy to create a lib that could be loaded as
> a part, I think. AFAIK there are tools that can (almost) automatically
> create language-bindings for foreign languages to access c++ libs, but
> I don't know if they can work the other way, I mean create a language
> binding for a foreign language so that a C++ program could load it as a
> shlib. I don't think this works, but please correct me if I'm wrong.

Just repeating: If you want to develop an OpenParts::Part, then you have
to use C++ . (as long as you don't want to re-implement all OpenParts
CORBA interfaces) .

> - it kills cross platform operation. The corba solution allowed
> (theoretically) to run a part on a highend-level-server and embed it's
> screen output as a Part into KSpread. This would be gone, I guess.

Yes, it would be gone, but IMHO it's worth the drop this feature, compared
with what we gain with Canossa.

> A question: Is it possible with the canossa way to embed a window that
> was forwarded via the X11 protocol? If yes, the only thing that can't
> be done is the parts-specific toolbar/menubar ?

Creating a GUI is not enough, you also have to connect to it. Canossa
solves this via the action concept of Qt, which is only possible because
the shell can (directly) access the actions of the embedded part.
 
> Torben seemed to solve this via XML. So a part can have a static
> toolbar/menubar layout, but no dynamic (context sensitive) one? If this
> is no longer possible, then "the canossa way" would be a bad idea.

I already asked Torben about this and I'm sure that Canossa will a dynamic
layout aswell.
(BTW, parts of it are already dynamic. If you change the text of a
QAction, then the Menu-Item for example is updated on-the-fly)

> The nice network-transparency of CORBA lacks encryption: afaik the
> datastream between server and client is not encrypted (?). Thinking
> about the information that could be transported via that channel, this
> is a serious security whole because anybody between could grab the
> stream and decode it.

MICO supports SSL.

> on the other side the shared libs solution kills the "multi threading"
> that was introduced by using CORBA.

I can't see any kind of multi threading CORBA introduced?
 

Ciao,
 Simon

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