kdom and khtml integration

[Frans Englich]

On Monday 27 February 2006 16:03, Leo Savernik wrote:
> Am Montag, 27. Februar 2006 00:21 schrieb Rob Buis:
> > Good evening khtml hackers :-)
> >
> > As some of you may know we have been working the last
> > year(s) on kdom/ksvg2/kcanvas - three seperated projects. The initial
> > aim was to decouple the whole DOM from the HTML stuff, which is contrary
> > compared to khtml itself. We've now reached a state where we actually
> > need integration of at least ksvg & khtml to support fancy things like
> > CDF (ie. xhtml in svg or the other way round). WebKit+SVG has already
> > done that by creating SVG RenderObjects and coupling the projects.
> >
> > We haven't been convinced of this coupling so far, hence we introduced
> > a lot of things (CDFInterface, EcmaInterface, etc..) in the ecma & css
> > areas to be able to make kdom a "base" for ksvg and khtml which results
> > in a lot of 'virtual' usage, and more other things (don't want to
> > describe all in detail) which makes it impossible that our stuff will
> > ever be as fast as an integrated environment.
>
> Summarized, Apple went for the monolithic approach while you went for the
> componentized.

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.

If we put everything in one library, KWord's startup time is increased for no 
reason if it decides to adopt KXML: it have to bring in svg, html, ECMAScript 
support, and what not. The NodeImpl object wastes memory by its RenderObject 
pointer for no reason.

That's not attractive. It is monolithic, and forces stuff on people. I think 
KDE 4.0 is a great opportunity to build highly reusable, generic frameworks.

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.


Cheers,

		Frans