[Standards] [Operators] Future of XMPP Re: The Google issue

Peter Waher Peter.Waher at clayster.com
Wed Dec 4 22:48:02 UTC 2013


A small comment regarding EXI:

One option, though, is EXI, which "knows" - with some encouragement - to ship values as binary even though in traditional XML serialization, they'd be base64 encoded. My only worry is that the level of benefit that this gives is rapidly eroded by how good XML parsers have got, especially when you consider the overhead that known-schema causes to the complexity of the protocol.

XEP-0322 (EXI) contains two methods of using EXI-compressed XML in pure binary form, i.e. not base-64 encoded. The first method contains a handshake mechanism where a normal XMPP session is converted to pure binary using EXI (including quick setup), and another mechanism which is EXI from the start, i.e. no text XML is sent/received.

I would prefer to make a clean cut and to develop something like XMPP 2.0 or similiar which got rid of XML in favor of some header based protocol (e.g. protocol buffers or even something as simple like <type><length><optional_hash>content (in binary form, a bit more would be needed to enable nested types, but it's just to express how it should have been done).

I think it's relatively easy to exchange the XML-based parts of current XMPP-implementation to something like protocol buffers. All the concepts and other stuff would still work, but the really ugly thing of parsing stream based XML would be gone.

Having said that, some defense of XML: Using XML (either serialized as text or serialized as efficient binary using EXI) has some exceptional benefits, among other things its extensibility and interoperability. Being able to use standardized techniques for validation (schemas), version control and transformations (XSLT), searching (XPATH) etc. is a further plus. There are many attempts to create "simpler" forms of communication using for instance JSON, etc. But what is "simple" in the short term is not necessarily what is simple in the long term, especially if you want to create an interoperable infrastructure where myriads of service providers share common networks and supposedly integrate with each other, taking into account versions, contracts, etc. Making it too simple now, might end up bury you in the end.

Best regards,
Peter Waher

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20131204/7dbe5322/attachment.html>

More information about the Standards mailing list