Am 04.12.2013 15:16, schrieb Matthew Wild:
On 4 December 2013 13:56, Alexander Holler <[email protected]> wrote:
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).
Any reason not to use EXI when you need something like that? The only
downside I see is the need for schema negotiation, but protocol
buffers have the exact same problem.
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 then you have SIP :)
SIP is much more complicated. A subset might do the trick. Key is to
keep the core simple while extentable. Just like XMPP, except without XML ;)
