kdom and khtml integration

[Frans Englich]

On Wednesday 01 March 2006 15:21, Nikolas Zimmermann wrote:
> On Wednesday 01 March 2006 14:31, Frans Englich wrote:
> > On Sunday 26 February 2006 23:21, Rob Buis wrote:
> > > Good evening khtml hackers :-)
> >
> > Came to think of another thing:
> >
> > I don't think KDOM as it is now is suitable for kdelibs inclusion. css/,
> > core/ and events/ quite thoroughly spews compiler warnings and that isn't
> > very correct. It is also avoided in kdelibs, so it would lower kdelibs
> > quality.
> >
> > Likewise, there are admirable efforts for improving the Doxygen in
> > kdelibs. KDOMBinder does currently at best generate no doxygen but
> > regularly outputs invalid. I think it should be fixed, since otherwise it
> > would lower kdelibs quality.
> >
> > But that's just my personal view on how things should be, of course.
> >
> >
> > Cheers,
> >
> > 		Frans
>
> Hi Frans,
>
> you may have misunderstood something. There won't be a KDOM
> in kdelibs at all - we will integrate within khtml.

I am bewildered by what you write. I've now three or four times tried to make 
us take a close look at this monolitihic vs modularized issue. I've not 
objected to anything, all I've said is let's discuss this, let's analyze 
this, let's bring in all our different views, requirements and competences on 
this.

This is pretty much all I know: the reason to build a monotlithic library is a 
performance gain which outruns that all other applications that doesn't need 
SVG/HTML rendering gets increased startup time for no reason and an increased 
memory consumption that scales linearly with document size for no reason. I 
haven't seen an analysis concluding why all other solutions apart from 
building a monolithic library fail.

I'm saying that we should analyze and discuss it, such that there is substance 
when you use the word "we".

All my alarm bells go off when I hear that modularization is sacrifized in the 
name of performance. Especially when the motiviation is vague and that many 
interesting alternatives exists. The trend in kdelibs is to build 
specialized, modularized libraries and I want khtml/kdom to follow that, not 
go in the opposite direction.

It is a long step from "we think here is a significant negative performance 
impact" to concluding that the best solution is a decision on the library 
level. If one wants to avoid call dispatching in a hot code path there are 
many solutions which works without sacrifizing modularization. It also scares 
me to discuss performance without numbers, especially with the complex 
systems in KDOM/KHTML and that little is exported and therefore inter 
procedural optimizations can be quite effective.

Couldn't you describe exactly what problematic areas you think exist, and why 
the various modularized approaches fail, according to your opinion? I think 
many would appreciate if you did that.

> That means we won't 
> port all-in-one-shot, but in little manageable pieces. That includes
> regression testing, regression testing, regression testing. I for
> sure wouldn't want to introduce new warnings/errors/bugs.
>
> I'm not seeing your point. I want constructive discussions,
> mails like these don't help at all. 

We see it different ways; I find the mail constructive. The second KDOMBinder 
generates broken documentation since it was deployed. Warnings in KDOM have 
been cleaned up, but afterwards introduced again. That suggests it 
have had low priority.

I find it constructive to identify problems, to say "this and this must be 
better", and to build a goal that must be reached. Sure, it sounds a bit 
depressive since it "says no" and pulls the break. But all is fine, "I sure  
wouldn't want to introduce new warnings/errors/bugs" is all that's needed to 
know this has the necessary focus.

I would also like to see KDOM(and khtml) to compile with stricter options: 
-Wold-style-cast and -pedantic. I do that for my areas in KDOM(about 40% of 
the code), but it would be cool to see it in all code.

> And yes, I'm a bit angry.


Cheers,

		Frans