Provide an API compatible abstraction to use node-xml as node-expat

[dhruvbird]

https://github.com/robrighter/node-xml

This allows anyone to use it (independent of platform) since node-xml is pure javascript (no C-bindings to libexpat1).

However, this comes at a cost:

• Reduced performance. See https://github.com/astro/node-expat#speed
• Some security mods like restricting stanza size might be unavailable
• I'm also unsure about the continued maintenance of node-xml

This mode would be discouraged, but hopefully supported some time in the future.

[sonnyp]

I don't know if it helps but ltx support different backends
https://github.com/astro/ltx/tree/master/lib

node-xml is one of them

[dhruvbird]

ltx support different backends

Didn't know this - thanks for the info!

We use the SAX interface of node-expat, so this is of limited use for now :-/

[sonnyp]

What about switching to ltx?

[dhruvbird]

ltx doesn't have a sax parser - and it's used heavily to do the xml parsing since it's much more efficient to do that than dom parsing. Besides, it isn't easy to locate xml message boundaries when data is received over a socket from the xmpp server.

[sonnyp]

https://github.com/astro/ltx/tree/master/lib

Please see sax_node-xml.js

[dhruvbird]

@sonnyp That's an interesting starting point!
nxb uses methods specific to node-expat (such as getCurrentByteIndex) which are used to limit the buffer size and prevent buffer-build-up attacks against the bosh proxy.
It would be possible to build a failure mode that doesn't support these features and lacks these functions, but I don't see too many people asking for a windows build.
While it would be super to have something that works, it feels that having something that works and is performant and has all the required features might be a stretch in the near term :-/