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
presence:
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).
Regards,
Alexander Holler
