[Operators] Future of XMPP Re: The Google issue

Alexander Holler holler at ahsoftware.de
Wed Dec 4 14:30:08 UTC 2013


Am 04.12.2013 15:16, schrieb Matthew Wild:
> 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 :)

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 ;)



More information about the Operators mailing list