(Here is my take on things --- I hope other khtml contributors will responde as well)

> Hence we think for the future it makes more sense to go the "integrated"
> way, aka. kdom & ksvg & khtml all in one library. 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

Sounds nice.

>
> kxml's dir structure could be assembled similar to WebKit:
> kxml/html, kxml/svg, kxml/rendering, kxml/core etc..

I think my answer on one-class-per-file thing answers how I view this.

>
> Here is an unordered list of the "good things from kdom":
> * One-Class-One-File policy aka. having kxml/core/NodeImpl.cpp AttrImpl.cpp
> etc.. 

I would actually consider this to be a Very Bad Thing.

Amongst disadvantages:
- Longer compile times

- Much harder to work on related areas of code: while right now one can open 2-6 files and be done, 
this would potentially involve opening 30+. Also consider e.g. working on attribute handling. That
generally involves touching AttrImpl, AttributeImpl, NamedAttrMap, ElementImpl, etc. These are now
all nicely in the same file, so one can get a decent overview without scooting 
around. Not to mention do you really think classes whose implementation is this long:
ChildNodeListImpl::ChildNodeListImpl( NodeImpl *n ): NodeListImpl(n, CHILD_NODES)
{}

bool ChildNodeListImpl::nodeMatches( NodeImpl* /*testNode*/, bool& doRecurse ) const
{
    doRecurse = false;
    return true;
}

deserve separate files?

- Difficulty of maintaining both 3.5.x and 4-pre branches: automatic merging will become impossible, 
and it'll be hard to compare the tree. You already should be aware of this --- how easy is it for you
to compare matching classes in KDOM with those in KHTML?

- Loss of version/revision history. It would become much harder to trace back the rationale for 
some changes. SVN is already a pain in the butt for that!

- Why change stuff that works w/o observable user benefits? 

> * Multiple parsing backends (ie. libxml2) 

We need just one that works well, and hopefully wouldn't link to multiple XML libraries at once.


> * Standalone XML processing facilities (KDOMParser / KDOMDocumentBuilder &
> friends) 

<snip XML stuff I don't care one bit about>


> Please note that Webkit+SVG clearly shows that integrating svg with (x)html
> can be done. Also our prototype, which groups ksvg2 and khtml2 and makes
> use of SVG render objects in the same way as in Webkit, can handle
> xhtml+svg fine, see for instance
> http://www.xs4all.nl/~rwlbuis/simpleCDF2.png
>
> So, here is our proposal:
> 1. Split up to more files, like kdom/ksvg & WebCore does,
>    for example dom_nodeimpl.h -> NodeImpl.h.

See above.

>
> 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 would really appreciate if someone explained what they're actually -good- for. (QName particularly)
What I see most is that e.g. QualifiedName really uglifies the places where we have switches. 
And while I am not really happy with the name -> ID mapping code currently, that's no 
reason to throw out the integer-ID concept.


> 3. Merge in "best of kdom"

It would be nice of you elaborated on the cool stuff you have there. Or is the list 
below supposed to be there?

> 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.

Yey!

>
> 5. Merge in a subset of kcanvas into khtml/rendering.

Yey!

>
> 6. Nice to have: do autogeneration of cpp/js bindings?

In principle.

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

To me, that name would suggest it's a mere XML library.


Good luck,
Maks