[Development] Replace QtXml backend

Gerhard Scheikl g.scheikl at avibit.com
Mon Jul 27 09:58:42 CEST 2015


On Friday 24 July 2015 08:50:07 Thiago Macieira wrote:
> On Friday 24 July 2015 15:26:30 Gerhard Scheikl wrote:
> Hello Gerhard
> 
> Your question is answered mostly by your paragraph above: QtXml is in Done
> state, so we really don't want to do major surgery in it, which could open
> the door up for subtle incompatibilities.
> 
> I'm not even talking about introducing bugs that aren't there. That's sure a
> concern. But even if you do your best, you may *fix* bugs that people are
> accidentally depending on; or the simple fact of a change in behaviour
> could result in existing code getting broken.
> 
> Are you prepared to accept all of those reports and react to them?

Hi

I didn't fully think it through yet, was just an idea. :)

> > So we came up with the idea to replace the back-end with Xerces and try to
> > leave the Qt API part the same.
> 
> That's interesting.
> 
> How big is Xerces?

Around 260k LOC.

> How easy is it to build?

./configure && make && make install

> How is it licensed?

Apache 2.0

> > If we succeed, we would like to give this code back to the community and
> > replace the current QtXml classes.
> 
> Do you include accepting maintainership of the module and reacting to bug
> reports in "give this code back to the community"?
> 
> We're all for new and improved code, but when it comes with a large
> maintenance burden, we have to analyse whether it's worth the hassle.

We have to maintain our code anyway. We definitely need to create a library 
that allows us to bring fast and working XML processing to our Qt backend.
Even better if we get external bug reports.

Maybe creating a 3rd party library would be the better choice.
Maybe creating something like QtXml2 would be an option.

What do you think?
Could we arrange a conference call to talk about options?

Thanks!

Best regards,
Gerhard



More information about the Development mailing list