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

List:       koffice
Subject:    Re: More thoughts about the filter architecture
From:       David Faure <david () mandrakesoft ! com>
Date:       2000-03-07 17:12:54
[Download RAW message or body]

> Just imagine us adding all kind of data access methods (setXYZ(), xyz(),...)
> to the (crowded) KoDocument-derived class interface.
That was not the plan, of course. "Correctly"-structured apps
have separate data classes (Kspread's map and cell stuff,
KPresenter and KWord's paragraphs and such...).
Such an API (and I guess that not a lot is missing) would be
good for scripting anyway.

> Of course. But then we have to ensure that each filter only needs the
> KoDocument data of its part. We could even go for a "mixed" solution
> (partly direct acces (KoDocument) for critical stuff, partly XML
> (all the rest))...

I think we should stop thinking about a new solution, and consider the
question from another angle: "What do filters need ?" That is the main question.
If we do this all new architecture just so that KSpread can export
values in cells, it's plain wrong ;-))
The KIS thing was mentionned too, but there again there is a solution.

* If we need direct access to the document or any other object
for some other purposes, it would be time to identify them
(what about the olefilters ? Hmm, I guess they don't need that)

* If we want a new architecture so that we gain on efficiency
(by avoiding writing to a temp XML file and then parsing in the part,
or vice versa), then keeping both methods is, ahem, stupid.
(Except temporarily, of course).

I sort of have changed my mind. What is the point in doing
some big changes if we don't need them...
So first, the question is, do we need to change the architecture.

> Does this bloat the filter libs? I'm no linker freak, but I think
> this shouldn't be a huge problem.
Since the process that loads the filter already has its own
lib loaded in memory, this is really no problem !

> There is no big difference to our "new" solution anymore. It's
> quite "monolithic," too. I know that it's not exactly the same,
> but there are some similar effects (e.g. it has to know a lot
> of implementation details,...).

Oh yes, sure, I fully agree !
It's the _current_ solution that is not monolithic...

> > Hmm, sure, that could be the reasoning here:
> > * filters are external because all they need is the XML file,
> > as an input (export) or as the output (import)
> 
> This is what I thought, too. But I totally forgot that it's in
> the same process since we use kparts. Therefore this argument is
> void from the "let's crash the part" point of view :)
Yup.
> Sure it's easier for the filter programmer to handle two files
> instead of data structures (monolithic way) in a huge program
> she/he didn't write. This abstraction is quite "expensive" in
> terms of speed and direct accessability, of course...
Yes.

> It's a nasty hack, but since it's no separate process we should
> try to use the new possibilities.
_If_ we need them ;-)

> Pheew... this one's quite long. 
Indeed - I cut the stuff I agreed with, but I added even
more ramblings ;-))

> What about a <normally I don't like it>IRC session</normally I don't like it>???
;-)

> I simply assume that you read this mail soon and suggest meeting
> at 20:00 CET (should be 19:00 GMT???) on #kde. If you miss this
> "deadline" I'll be on #kde every hour till we meet or I fall
> asleep :)))

Ok, I'll be there - but I wanted to post this first anyway,
because there was quite a lot of stuff to say...
Feel free to reply on the list first if you prefer.

> If there is anyone else who wants to discuss this topic - you know
> where to find us.
Given the participation on the list, I doubt it ;-)

-- 
David FAURE
david@mandrakesoft.com, faure@kde.org
http://home.clara.net/faure/
KDE, Making The Future of Computing Available Today

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