Re: [Development] Replace QtXml backend

31.07.2015, 10:43, "Sylvain Pointeau" : > On Tue, Jul 28, 2015 at 9:51 AM, Gerhard Scheikl wrote: >> I found a nice image on stackoverflow: >> http://stackoverflow.com/questions/9387610/what-xml-parser-should-i-use-in-c >> >> If it is true, then our choice would be xerces because libxml2 doesn't

Re: [Development] Replace QtXml backend

On Tue, Jul 28, 2015 at 9:51 AM, Gerhard Scheikl wrote: > > I found a nice image on stackoverflow: > > http://stackoverflow.com/questions/9387610/what-xml-parser-should-i-use-in-c > > If it is true, then our choice would be xerces because libxml2 doesn't > have an > exact DOM/SAX API compliance.

Re: [Development] Replace QtXml backend

On Monday 27 July 2015 23:21:02 Cristian Adam wrote: > On Mon, Jul 27, 2015 at 6:03 PM, Thiago Macieira > mailto:thiago.macie...@intel.com>> wrote: > > On Monday 27 July 2015 09:58:42 Gerhard Scheikl wrote: > > > How is it licensed? > > > > Apache 2.0 > > This is a deal-br

Re: [Development] Replace QtXml backend

On Monday 27 July 2015 16:25:10 Thiago Macieira wrote: > > Reusing libxml2 and libxlt should actually cause code decrease. > > Huh... not really > > It would cause a minimal decrease for anyone using qtwebengine, but it > would increase the code size for everyone who isn't. Remember that every

Re: [Development] Replace QtXml backend

On Monday 27 July 2015 23:43:06 Cristian Adam wrote: > libxml2 and libxlt are already part of the Qt source tree, part of > QtWebEngine-chromium > http://code.qt.io/cgit/qt/qtwebengine-chromium.git/tree/chromium/third_party > /libxml > http://code.qt.io/cgit/qt/qtwebengine-chromium.git/tree/chromi

Re: [Development] Replace QtXml backend

On 7/27/2015 11:21 PM, Cristian Adam wrote: On Mon, Jul 27, 2015 at 9:58 AM, Gerhard Scheikl wrote: 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.

Re: [Development] Replace QtXml backend

On Mon, Jul 27, 2015 at 9:58 AM, Gerhard Scheikl > wrote: 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 in

Re: [Development] Replace QtXml backend

On Monday 27 July 2015 14:24:27 Gerhard Scheikl wrote: > > QXmlStreamReader is not a SAX parser. > > But the approach is very similar. Both are "iterative". :) Indeed. The term is "StAX parser". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technol

Re: [Development] Replace QtXml backend

On Monday 27 July 2015 09:58:42 Gerhard Scheikl wrote: > > How is it licensed? > > Apache 2.0 This is a deal-breaker. > Maybe creating a 3rd party library would be the better choice. > Maybe creating something like QtXml2 would be an option. QtXml2 under an LGPLv3 licence might be a acceptable

Re: [Development] Replace QtXml backend

On Monday 27. July 2015 14:24:27 Gerhard Scheikl wrote: > On Monday 27 July 2015 09:47:34 Knoll Lars wrote: > > With the old QXmlReader or with QXmlStreamReader? > > We are currently using QXmlSchemaValidator for the validation. > > > QXmlStreamReader is not a SAX parser. > > But the approach is

Re: [Development] Replace QtXml backend

On Monday 27 July 2015 09:47:34 Knoll Lars wrote: > > With the old QXmlReader or with QXmlStreamReader? We are currently using QXmlSchemaValidator for the validation. > QXmlStreamReader is not a SAX parser. But the approach is very similar. Both are "iterative". :) Best regards Gerhard ___

Re: [Development] Replace QtXml backend

On 27/07/15 11:23, "Gerhard Scheikl" wrote: > >> 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

Re: [Development] Replace QtXml backend

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

Re: [Development] Replace QtXml backend

On 27/07/15 09:58, "Gerhard Scheikl" 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 d

Re: [Development] Replace QtXml backend

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

Re: [Development] Replace QtXml backend

On Friday 24 July 2015 15:26:30 Gerhard Scheikl wrote: > Hi > > Unfortunately, the QtXml classes contain a lot of bugs and are not really > maintained. 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

Re: [Development] Replace QtXml backend

On Fri, Jul 24, 2015 at 3:26 PM, Gerhard Scheikl wrote: > Hi > > Unfortunately, the QtXml classes contain a lot of bugs and are not really > maintained. > So we came up with the idea to replace the back-end with Xerces and try to > leave the Qt API part the same. > > Hi, pugixml has a benchmark

[Development] Replace QtXml backend

Hi Unfortunately, the QtXml classes contain a lot of bugs and are not really maintained. So we came up with the idea to replace the back-end with Xerces and try to leave the Qt API part the same. Has anyone tried such an approach already? If we succeed, we would like to give this code back to