One of the harder things with XMPP is that it is a badly-formed document up until the connection is closed. You need a SAX-style/event-based parser to handle it. That makes rolling your own understandable in some cases (e.g. dotnet's System.Xml couldn't do this prior to XLinq).
That being said, as you indicated Gloox is C-based, and the reference implementation of SAX is in C. There is no excuse.
Not only that, but before the TLS session starts you have to handle an invalid XML document (the starttls mechanism start encrypting stuff right in the middle of the initial XML document).
Also some XML constructs are not valid in XMPP (like comments)
I think rolling out your own XML parser for XMPP is a fairly reasonable thing to do. In the past at least, many, if not most, implementations had their own parser (often a fork of a proper XML parser). What is more surprising to me is why would they choose XMPP for their proprietary stuff. I don't think they want to interroperate or federate with anything?
(if I remember correctly and if it hasn't changed compared to many years ago, when I looked at that stuff.)
> One of the harder things with XMPP is that it is a badly-formed document up until the connection is closed. You need a SAX-style/event-based parser to handle it.
That is a common misconception, although I am not sure of its origin. I know plenty of XMPP implementations that use an XML pull parser.
Smack uses an XML pull parser and non-blocking I/O. It does so by splitting the XMPP stream top-level elements first and only feeding complete elements to the pull parser.
That being said, as you indicated Gloox is C-based, and the reference implementation of SAX is in C. There is no excuse.