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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
