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
