Suggestion: migrate to pugixml

[niello]

Hi all.

There is an issue to drop rapidxml in favour of pugixml. But what if we drop all XML parsers and use pugixml only? According to benchmarks it is one of the fastest XML parsers and has reasonable memory footprint. Version 1.9 with XPath disabled has DLL size of 75 KB. Is it really necessary to support a whole zoo of XML parsers? We can get rid of XMLParser abstraction level and corresponding cmake messing, and user can keep using his/her XML library of choice outside CEGUI for almost no overhead in a build size (or use pugixml and have no overhead at all).

What do you think?

[Ident]

That was my suggestion as well but it was turned down by CrazyEddie to drop support for all the other parsers.

Imo, we should first make a pugixml parser and then we can make it the default and main one, once it is proven to work well.

Then we can bring this up again. I also do not think we should support "a whole zoo of XML parsers" as a Windows user but honestly I can't estimate how people on Linux distributions think of this.

[niello]

I think there must be no difference for Linux users as CEGUI uses an XML parser only internally. It is completely transparent from outside, and building CEGUI becomes the only concern. We use particular libraries like freetype not giving the user ability to choose, so it is normal to have some hard dependencies. And I think that XML parser is exactly the same case, because it doesn't affect user code and because CEGUI can't operate without XML parser. In the worst case user will have 2 parser libraries in a project, but currently there are parser itself + mandatory CEGUI wrapper = 2 libraries too.

So yes, I can implement pugixml wrapper, but the point of discussion is to dismiss wrappers at all. If we do, writing pugixml wrapper is an useless work as this code will be thrown away soon. If we don't then yet another XML wrapper may wait until more important tasks are completed:)

[Ident]

Why would we dismiss wrappers in general? There is a point of having interfaces here since projects might already use an XML parser of some sort for some reason and we do provide an interface for this for the rendering api as well. What makes XML parsers different?

[niello]

Because reading & writing XML is always reading & writing XML. No variations except in performance. No option to have CEGUI resources with some particular library specific features (and this is good). Yes, we allow users to plug in their XML libraries, saving them near 50 KB of binary in the best case, but adding a layer of complexity and abstraction, which affects project setup complexity and (almost sure) performance.
Can you name some benefits of having XMLParser wrappers instead of tiny & fast library embedded directly into the resource subsystem?

[Ident]

The XML parsers vary in features. Just a quick one I can think of without investigating: CEGUI has xsd files, you can't validate your files with them using only pugixml... I think we always used the Xerces library for this which is slower and more heavy weight.

[niello]

Then we can close this discussion. I thought there is no functional difference.

[Ident]

Adding pugixml support would still be welcome btw