Re: Hrm. Now I know why this list is dead

[Cristian Tibirna <ctibirna total net>]

On Tue, 25 May 1999, Havoc Pennington wrote:

> This is a matter of a) exporting CORBA interfaces from the apps and b)
> writing appropriate language bindings for ORBit (Mico already has Perl,
> C++ and maybe others)

Python has an own ORB (of course, can then communicate with any
ORB-enabled app). Python is very well included in KDE already.

Same could become easily true for Perl (I personally know less about Perl,
though).

> I would tend to suggest writing C++ bindings for ORBit then dropping Mico,
> since ORBit is a lot faster anyway. This avoids lots of effort duplication
> as we add additional bindings. But I'm not going to do it, no time.

This proposition needs much more analysis than this. MICO is presented in
many places as slow (and even its authors are stressing MICO is meant to
be firstly stable and only then efficient). However, MICO is
*full-featured* and *stable* and *secure*.

Another thing about MICO it's that it is developed independently (so the
desktop developers don't have to distract themselves with an ORB
development as a supplement) and is designed and well supported by
dedicated specialists.

And however, the ORB an app uses is not important. The interfaces are.

> The issue is whether KDE and Gnome apps will export the same interface for
> doing the same things. For example, right now we are trying to reverse
> engineer the interface between Excel and its chart component (and not
> getting very far); but anyway, once it's done, it would be nice to share
> that interface between Guppi and KChart.

This is another point to analyse. There is a big danger in perpetually
reinventing the wheel here. KSpread used successfully, since more than a
year already, CORBA/KOM to communicate not only to KDiagramm, but to all
the other KOffice members.

(Honest question: ) What would be the advantage in reverse engineering the
charting interface in Excel and using it? If I understood well, KOM is
much superior to the technology microsoft uses inthere, because document
objects are XML-based (thus world readable) and network transparent.

Why not look at already defined IDL's in KDE (KOffice, Konqueror and the
mail IDL) and K object model (as being already fairly usable and stable)
and develop on top of it if the analysts will agree on them. We could
avoid reinventing the things here. And we could use the advantage of
already having something (a base) in KDE's constructs.

> This is just a matter of writing up some IDL and saying "OK, we will both
> use this IDL." This does mean the IDL doesn't necessarily map trivially to
> the internals of each app.

OO techniques simply render moot the triviality problem.

Opinions?

Cristian
... a mere novice in ORBs, but willing to learn ...