[no subject]

and

"In short, a good component technology has the following
characteristics:

    * it is easy to enable an application as a component
    * it is easy to use a component in another application
    * the component is activated quickly (almost instantaneously).

Corba meets none of these requirements, while KParts meets all of them.
Corba is a very good technology but it is definitely not suited for gui
components. Read what follows to see how KPart is a success in this
area."

The author misrepresenting Bonobo here. [classical usenet style
reasoning: A uses B, A is difficult, therefore B is difficult]

While Bonobo is based upon CORBA, it provides default implementations
for most stuff, so most of the time, you don't have to implement and
interfaces at all. My example above shows that. However, you can if you
need to.

KPart seems like a glorified shared library loader; there's nothing
wrong with that, in fact, it's a lot easier to implement, and has some
performance advantages (but you can optimize shared library
CORBA-servers to approach virtual function call speeds - in fact works
being done in GNOME's ORB (ORBit) to achieve this).

On the other hand, Bonobo's CORBA-base allows for flexibility which is
not possible with KPart (as far as I can see):

1) out of process components=20
2) components on other machines (may not be suitable for GUI-components,
but perfectly reasonable for non-GUI-components)=20

note that 1) and 2) can be done transparently -- client doesn't have to
know where components live.

3) interaction with other languages (e.g. you can use Bonobo from C++,
Perl, Python, Guile,...). It would be hard to write a KParts-component
in Perl, I guess...

4) Allows for independent implementations (e.g. there's a Java-based=20
implementation of Bonobo, 'MonkeyBeans').

=20

--Dirk-Jan.

--=20
--------------------------
Dirk-Jan C. Binnema=20
mail: djcb djcbsoftware nl=20
web: www.djcbsoftware.nl=20
icq: djcb/65417888=20
--------------------------