I work on a large Go project implementing a XMPP  chat server. One of
our biggest problem is handling XML in a clean way . I'm currently
trying to improve our approach to the problem, and writing this message to
seek advise from the community. Some of this may seem negative, but I'm
genuinely happy with Go overall, and also interested in contributing to
making things better.
The Marshal/Unmarshal interface of encoding/xml is at fundamental odds with
the XMPP protocol. Unmarshal/Marshal expect XML that can be mapped to a
static structure . XMPP requires processing of XML that may have a
static structure at its core, but can be extended with arbitrary elements
and attributes by servers and clients alike .
So for all practical purposes, XMPP requires a DOM  / Tree kind of data
structure. Additionally XPath is really nice to have (but one can do
And this is where things get tricky. There currently doesn't seem to be a
mature DOM implementation for Go. xmldom-go  comes close, but has seen
no commits for 9 months and looking at the code, I suspect it would take a
lot of effort to finish it and clean it up. So at this point the only
mature solution seems to be libxml2 via gokogiri , which is what we
ended up with so far. However it has two major problems:
1. It introduces manual memory management into a garbage collected
environment. While Go makes it easy to create C bindings, they're
incredibly annoying to use in practice because of this. SetFinalizer looks
like it could help, but the guarantees it provides are currently too weak,
and it's my understanding that there are no plans to change that.
2. libxml2 has a really nice API for parsing streaming XML, but it doesn't
really work  and I've had no luck getting the maintainers attention for
the patch I provided .
The end result of these two problems is that we're forced to do manual
memory management (which has lead to bugs causing segfaults, panics,
infinite loops and data corruption) as well as using encoding/xml to buffer
up individual XML stanzas before parsing them for a second time with
gokogiri : (.
Additionally we've also been unable to use encoding/xml in more simplistic
marshal scenarios involving namespaces, but maybe this is just our
inability to use the API correctly ?
Anyway, at this point we're between a rock and a hard place when it comes
to handling xml. It seems like implementing a simple DOM pkg + support for
basic XPath for our internal needs may be the best solution for now, but
that's not going to make things any better for the community, as we'd
rather not release another incomplete/ad-hoc solution into the ecosystem.
So I'm wondering if anybody has advise. Are there plans of adding a
DOM-style API to the go core? If yes, I'd like to help. If no, does anybody
see any feasible alternatives for our situation? 
Many thanks in advance,
: I use the term "static structure" to describe compile-time defined
structures made up of structs and slices, rather than a Tree/DOM-like data
: Have a drink if you laughed, otherwise continue on.
: The complexity of XMPP is worth a discussion as well, but we're stuck
with it for this project.
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
For more options, visit https://groups.google.com/groups/opt_out.