[Development] Replace QtXml backend
Knoll Lars
Lars.Knoll at theqtcompany.com
Mon Jul 27 10:57:01 CEST 2015
On 27/07/15 09:58, "Gerhard Scheikl" <g.scheikl at avibit.com> wrote:
>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.
Did you consider using QXmlStreamReader/Writer instead of the old QXml?
These classes are fully compliant, well tested and very fast. The only
drawback is that there is no equivalent to the QDom* classes, but in most
cases you’re better off parsing directly into your own data structures
anyway.
Cheers,
Lars
>
>What do you think?
>Could we arrange a conference call to talk about options?
>
>Thanks!
>
>Best regards,
>Gerhard
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development
More information about the Development
mailing list