Look into replacing RapidXML #83
Comments
|
With the discussion about streaming support PugiXML may not be the best choice - it certainly seems like a great choice for a DOM like model, but it wouldn't support streaming. We can either provide a single XML archive that supports streaming or have separate streaming and non-streaming versions. Either way, this leads to the issue of finding a suitable XML library to perform streaming serialization. It'd be very preferable if we didn't have to write something from the ground up since it seems like both a lot of work and something prone to introducing errors. |
|
Why not libxml (http://xmlsoft.org/) or tinyxml2 (https://github.com/leethomason/tinyxml2). Both are robust xml parsers and writers that support streaming. Just some food for thought. |
|
Really for cereal's use-case having to store the a full representation (be it DOM or JSON) seems unnecessary, we really only need it to keep objects in memory long enough to deserialize them. Better for security too (we don't waste resources on potentially large invalid objects). Not that cereal should be exposed to user input just yet but it's good to keep it in mind for the future. Plus streaming is actually simpler as the parser doesn't need to worry about how to represent relations between nodes as much, it just emits events in order and let's the listener take care of it. Of course most users want a full DOM if they are directly interacting with the input but cereal users aren't |
|
I like the idea of incorporating a common core of text parsing into cereal that could be used to create both a streaming XML and streaming JSON archive. There's a lot we don't need to handle since we have a fairly restrictive structure (and all we need to do is ignore things that we can't read anyway when parsing). I'm going to push this issue for a later release than 1.1 since it will be a decent amount of work and let 1.1 be more of a minor feature and bug fix release. |
|
Another option: http://isocpp.org/blog/2014/05/libstudxml |
|
Since Milo has revived his RapidJson project which really is very fast it would be nice to see him support XML in the same way in his lib now too! |
|
I'm a fan of this discussion, but if a hand-rolled solution is picked, I'd really like the performance to be priority. Too many json parsers are unacceptably slow when scaling to load save game information (like 500 kb of text). RapidJson is pretty solid for performance though! I know this is a discussion of XML, but if Json is also taken on just wanted to get this sentiment in. |
|
Actually Milo supports my idea of having his lib read both JSON and XML. He might work on this after v1.0 of RapidJSON is out, which shouldn't be long. |
As pointed out on the /r/cpp thread, RapidXML is no longer being actively supported, and PugiXML looks like a good candidate for replacement. Seems to have a cleaner interface too.
The text was updated successfully, but these errors were encountered: