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

[Cristian Tibirna <ctibirna total net>]

On Tue, 25 May 1999, Havoc Pennington wrote:

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

Oh! Sorry, I should have checked my facts. Languages support, featurism
and security remain though.

All that I try to say is that if one ever would have his head in a vice
about deciding what ORB to use, I think the only logical thing to do is a
thorough analysis. Merely *saying* one is faster doesn't conclude
anything.

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

True. And a big deal though. We can only wait for an ORB to become the
most popular then. Something in the vein of gcc, glibc etc. I mean, there
are so many compilers on Unix, but gcc is oh! so clearly the most popular.
And until then, let's accept the RAM/build-time overhead if no other
solution.

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

Pardon me? I strongly doubt that. Unless excel/chart communication can
write mail and run flight simulators. There is only one command and a set
of data to transfer. The rest is flowers. Or I humbly think so. FWIW,
KSpread/KDiagramm works very well. This is what is important.

I think I mean a real argument in favor of that Excel thing.

> (As an aside: it would be a lot easier to look at these interfaces if the
> office components weren't in one giant tarball!)

CVS? There are anonymous CVS mirrors. KOffice is publicly available in as
small chuncks as one wants. From 2 years already.

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

We can get fair reports each on his side. Do you take it, Havoc?

First, I think Bonobo's counterpart is OpenParts, isn't it?

Heck. I didn't do my homeworks. What is Baboon, what is Bonobo?
<Friendly_blunder> with so many monkeys, /me never gets all of them right
</Friendly_blunder>

I can start by saying that KOM/OpenParts was fairly largely redesigned and
written up to a stage where it's the most stable part of the object model
implemented in KDE. There is full support for "Document View" technology
and a fully featured trader with a nifty "minimum overhead" implementation
is available for any app to use.

In KDE, what is mainly remained to do in the direction of complete object
management support is IDL's.

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

I stick to my opinion. Good OO design helps *a lot* (and I should enter in
material example details I don't have prepared if I wanted to explain).
It's true that corbadizing such an app as XEdit is maybe a completely
offminded thing :-) But an app written from the ground up with a good OO
insight and an attention for immediate or later corba orientation is
surely not similar to 10 years old athena apps.

Thanks for listening.

Cristian

Cristian Tibirna     : ctibirna@total.net     : www.total.net/~ctibirna
PhD Student          : ctibirna@gch.ulaval.ca : web.gch.ulaval.ca/~ctibirna
KDE contact - Canada :  tibirna@kde.org       : www.kde.org