kdom and khtml integration

[Nikolas Zimmermann]

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.

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.

Bye
 Bye
  Niko