I noticed that XmlParser isn’t included as part of the runtime. Is there a good reason behind this?
Some of the work I’m doing uses pre-existing architecture and formats that can’t be changed. I could just use XmlParser anyways and include it with the Runtime as a modification, or even use something like RapidXml as an interim solution, but before I start shuffling things around is there a good reason behind sticking XmlParser under the Developer part of the toolchain instead of the Runtime?
I would imagine that in its current scope other formats are much better for parsing at run time.
The other possible reason will be whether or not run time actually needs .NET to run. If the XmlParser was built on an existing .NET library then that won’t work. Take that with a grain of salt though, as that is just a guess.
It doesn’t have any dependencies on .NET from what I can see. All in all, having XML parsing as part of the runtime would be kinda handy for those of us who have to work around constraints such as pre-existing file types, or having to conform to a given standard that requires an XML parser.
Here’s some background:
The XmlParser module was originally built as part of the .plist parsing for Mac & iOS platforms. I then split it off into its own module & augmented it a little (attribute & UTF-8 support, amongst other fixes) for use when parsing XML results from Subversion commands & error reporting. As such, it is only used in Editor & tools code at the moment, which is why it isn’t in the runtime.
I anticipate that XML parsing will be moved into Runtime pretty soon, just like Json already is. We still have a lot of cleanup to do - I am currently working on a generic UStruct serialization framework in Runtime that will support a number of formats. All formatters will likely be built on top of Core with no dependencies to the Engine or CoreUObject.
Maybe a long shot, but is EDN one of of those formats?
I have not considered EDN. I have considered BERT, which is Erlang instead of Clojure, but there is no use case for us right now. The most likely out-of-box candidates are Json, XML and BSON. Maybe MessagePack instead of BSON, not sure yet.
The good thing, however, is that formatters will be plugable, so you can easily implement your own formats as a plug-in.
In that case, it’d actually be kinda cool if you could support Eric Lengyel’s OpenGEX and its underlying OpenDDL format if you’re looking to have multiple supported data formats for serialization. It’s intended to function as a game engine focused alternative to JSON and the like, you can find more information on it (and some example Max and Maya plugins licensed under the creative commons) at the following websites: http://openddl.org http://opengex.org
Generic parsing of these data formats, including XML, would be really handy however since for many applications UStructs would probably be overkill - under many circumstances you just want a generic node tree of the data being represented in XML, JSON, and the like.
I suppose a good use case here would be XML-RPC for those of us who are working with pre-existing systems that depend upon the XML-RPC spec. Same would go for REST APIs where XML may be the chosen format for responses. On that note, when XML parsing moves into Runtime, it’d be nice to have support be on par with JSON, including the ability to parse a string containing the XML instead of having to read from a file.
Thanks, I was just hoping someone would save me the work 