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

[Havoc Pennington <rhp zirx pair com>]

On Tue, 25 May 1999, Cristian Tibirna wrote:
> 
> desktop developers don't have to distract themselves with an ORB
> development as a supplement) and is designed and well supported by
> dedicated specialists.
>

ORBit is as well. It is intended to be separate from teh Gnome project.
 
> And however, the ORB an app uses is not important. The interfaces are.
> 

I agree, they do interoperate. It's just that it's easier to maintain a
single ORB - saves some RAM and some build time. Not a big deal.

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

The Excel chart stuff has ten times the features of KChart/KDiagramm - I'd
like to see what interface they use to support all those things.
 
(As an aside: it would be a lot easier to look at these interfaces if the
office components weren't in one giant tarball!)

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

I don't know enough about Bonobo vs. KOM to compare.
 
Guppi (which is my app) is hyper-modular and could easily support a K or
KOM frontend, if someone was so inclined. I do think it is a very
different app from KChart, last I looked.

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

I don't think so; it is possible to structure apps in very different ways.
Some interfaces are too tied to a particular implementation. The fact that
it's only an interface doesn't magically enable all possible
implementations.

Havoc