[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:       "Dirk A. Mueller" <dmuell () gmx ! net>
Date:       1999-09-29 17:15:17
[Download RAW message or body]

Simon Hausmann <shaus@neuro2.med.uni-magdeburg.de> wrote:

Well, I can't build the thing, somehow the Qt CVS doesn't compile and I
don't have the time to figure out why.

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

Second: The "yet another API" Openparts wasn't a very good decision.
It's difficult enough for an "average" hobby programmer to learn Qt &
KDE bindings..

Therefore shared libs is a very fast and easy solution, BUT

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

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

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 ?

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.

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.

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

> (thus I fully support Torben's proposal)

The ideal would be a very "thin" CORBA layer, so that the parts can
still optionally run on a different machine ;-(



-- 
Dirk A. Mueller

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