[Operators] Future of XMPP Re: The Google issue

[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.

Regards,

Alexander Holler