kdom and khtml integration

[Frans Englich]

On Tuesday 28 February 2006 15:17, Nikolas Zimmermann wrote:
> On Tuesday 28 February 2006 14:50, Frans Englich wrote:
> > I'm a bit sceptical for the monolithic approach, and wish a closer look.
> >
> > Many KDE applications needs XML processing. For example, AmaroK have
> > invented its own tree because Qt's consumed too much memory.
> >
> > I want that KDE offers modularized, strong XML technologies that KDE
> > applications can use. There's more to it than rendering.
>
> [...]
>
> > I see two big distinctions: those who need to deal with XML as in
> > rendering, and those who have to deal with XML for data processing.
> > Perhaps the library layout can reflect that:
> >
> > * In one library we have ksvg2, khtml, ECMAScript, and rendering layer
> > tighly coupled. Anyone who need html most likely need ECMAScript or SVG
> > and vice versa, and it is efficient.
> >
> > * In the other library, used by the one above, contains DOM 3 Core, and
> > other raw data processing tools. If Kopete need to represent XML and do
> > an XSL-T transform or two, it gets that and nothing more.
> >
> > I would like a solution that holds for the next decade(that's KDE 4) and
> > that is efficient for the whole of KDE, not only khtml.
>
> Hi Frans & others,
>
> I tried to keep _exactly_ these points out of the initial discussion.
> We can still think of solutions if the integration in one library is
> actually _done_. Please do avoid these discussions at the moment.

You kept out the modularized approach in your initial mail for some reason; 
that you don't think it work or that it is not to your benefit, perhaps. The 
modularized approach is an alternative to the monolithic, and you have 
already settled on the former.

We are currrently at square one. Wouldn't it be great to consider whether 
another path is the right one, before we potentially go down the wrong one?

What is it you concretely are saying? That we spend time integrating it all 
into one library and after that go back consider if we should split it up and 
how?

> I want to get some work done in the next weeks, not discuss
> _completely_ new ideas like your String Handling thread on ksvg-devel,
> as well as this.

That idea is about whether the extra layer of DOMString/DOMStringImpl can be 
skipped in favour of using QString directly. It is a massive optimization and 
a fundamental change. That's exactly why I want it considered before we start 
working.


Cheers,

		Frans