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

List:       koffice
Subject:    Re: Stats for KSpread: opinion needed
From:       Roland Kaufmann <Roland.Kaufmann () student ! uib ! no>
Date:       1999-08-10 8:50:16
[Download RAW message or body]

John R. Zedlewski wrote:
> I guess my main question is this: what would we gain or lose, 
> in this case, by using a KOM wrapper rather than a shared lib. 
> If you have a spreadsheet with a series of embedded calls to 
> the stats library, you could easily end up with a table update 
> that requires several hundred CORBA calls.

Torben Weis wrote:
> I strongly vote for using the shared lib. CORBA is too slow
> for calculations!

I don't have much practical experience with MICO, so I'll have 
to ask the question: What is the overhead associated with a
library activation mode (http://www.mico.org/doc/node39.html)
compared to a custom, shared-library plugin?

CORBA is all about getting rid of loading shared libraries
yourself (plus a distributed aspect of course :-))

My advice is this: If you want this library to be an integral
part of KSpread, and KSpread alone then use a shared library
(so that the code can be loaded and unloaded from memory). If
you want the code to be accessible from other parts as well,
then write a KOM wrapper over the shared library.

The way I see it, the real issue here is not whether to make
it a KOM component or not, but how you are going to express
algorithms in an object-oriented model (ever wondered why STL
is not object-oriented?)

John R. Zedlewski wrote:
> I think the only real way to settle the KOM/shared lib debate 
> will be to actually shut up and try implementing both, then 
> compare them.

If you want to do double work. Personally I think a theoretical
discussion upfront can solve a lot of problems while they're
still on the drawing board where they are much faster to fix.

Of course, a dual implmentation makes sense if you're going to
expose a KOM interface to all other parts, but make KSpread use
the shared library directly (because of speed/design reasons).
But then you have already made a choice regarding KSpread, right?

Anyways, I think that you should make a KOM interface so that
other components could benefit from the library. (which you
must have thought of since you made a shared library in the
first place)

These are my *opinions* (as called for) alone. I'm not going to
do the implementation, so eventually you'll be the one stuck with
the decision about what to really do.

Sincerely,
	R.

---
No, I'm not an (e)mail-chauvinist.

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