kdom and khtml integration

[Germain Garand]

Le Lundi 27 Février 2006 00:21, Rob Buis a écrit :
> Hence we think for the future it makes more sense to go the "integrated"
> way, aka. kdom & ksvg & khtml all in one library. 

It sounds like a great plan...
I am agnostic /wrt the componentized vs. monolithic debate, so I trust you 
come up with the right decision.

> As khtml is de-facto 
> way more tested then our stuff we think that it's a good time now to merge
> the "good things from kdom" into khtml trunk, while ensuring no regressions
> are being introduced (of course :-). The next step would be merging
> ksvg(2) into khtml

Yes, a modular "merge/test/go on" process seem to make sense, and is what is 
best able to preserve history.
I must say: the well preserved history is an important asset of khtml. 
It documents a lot and makes the lack of manpower sometimes even bearable.

So my only concerns here are with regards to your prominent points of 
proposal:

> So, here is our proposal:
> 1. Split up to more files, like kdom/ksvg & WebCore does,
>    for example dom_nodeimpl.h -> NodeImpl.h.
>
> 2. Consider merging webkit datastructures like AtomicString/QualifiedName
> and ElementFactory. This is optional ofcourse, however we have good
> experiences with this functionality in kdom.
>

I don't understand why are these seemingly cosmetic/secondary points listed 
first?

I think like Maksim that those are more likely to lead to headaches and 
regressions than benefits if done beforehand... 

> 3. Merge in "best of kdom"
> 3a Merge nice APIs like KDOMParser/KDOMDocumentBuilder.
> 3b Merge core dom functionality like DOM3 Load/Save.
> 3c Import XInclude, XPointer, Catalog projects which make use of kdom APIs.
> 3d Discuss XPath future at a later stage of porting.
>
> 4. Merge in ksvg2 code.
>
> 5. Merge in a subset of kcanvas into khtml/rendering.
>

this is ambitious and excellent...

> 7. Consider renaming khtml to kxml, to reflect the improved xml
> capabilities.

as for this, I don't care much, but khtml's brand value is important too... 
other ways of bringing this to light should be considered, IMO.

not to mention that it is part of the UA string, which is the last thing you 
want to change if you are not fond of random regressions you can't do 
anything about.

Greetings,
Germain