[Operators] Future of XMPP Re: The Google issue

Alexander Holler holler at ahsoftware.de
Wed Dec 4 14:16:02 UTC 2013

Am 04.12.2013 14:56, schrieb Alexander Holler:
> Am 04.12.2013 14:05, schrieb Ralph Meijer:
>> Alternatively, it makes total sense to use a different protocol on PANs
>> and/or LANs and then bridge it to XMPP for WAN transport. For example,
>> Peter Waher is working on bridging MQTT and XMPP, and MQTT also has a
>> special profile for sensor networks based on non-TCP/IP settings, like
>> Zigbee.
> 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.
> Especially the problem that you need to parse the whole stream until you
> even know how long a packet (stanza) is, is a very ugly concept.
> Together with the surrounding <stream:stream> this is imho something
> never should have been done. XML was designed for documents (of fixed
> sizes, e.g. you get the size from the file system), but not for streams.
> Using another port, that would even be downwards compatible. What would
> be left, is to modify the presence stuff to get rid of the need for ever
> lasting (tcp) connections.

And to offer a simple replacement for the connection part in regard to 

Something like keep-alive-presence-stanzas. The interval would define 
how often a client polls for new stanzas and should be propagated with 
the presence state to other partners. So communication partners would 
still see if someone is considered to be online and it would enable 
those partners to see how long it might need until a message ends up at 
the client (and therefor how long a response might need).


Alexander Holler

More information about the Operators mailing list