[Operators] Future of XMPP Re: The Google issue

Matthew Wild mwild1 at gmail.com
Wed Dec 4 14:16:37 UTC 2013

On 4 December 2013 13:56, Alexander Holler <holler at ahsoftware.de> 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 :)


More information about the Operators mailing list