[Operators] Future of XMPP Re: The Google issue
Alexander Holler
holler at ahsoftware.de
Wed Dec 4 13:56:22 UTC 2013
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
More information about the Operators
mailing list