[Operators] Future of XMPP Re: The Google issue

Ralph Meijer ralphm at ik.nu
Wed Dec 4 13:05:48 UTC 2013

On 2013-12-04 12:00, Alexander Holler wrote:
> Am 04.12.2013 09:52, schrieb Peter Saint-Andre:
>> Hash: SHA1
>> On 12/3/13 5:02 PM, Alexander Holler wrote:
>>> Am 03.12.2013 23:55, schrieb Solomon Peachy:
>>>> On Tue, Dec 03, 2013 at 11:03:27PM +0100, Alexander Holler
>>>> wrote:
>>>>> So you think it is an elegant way that if a machine wants to
>>>>> send 10 binary bytes to another machine, it is ok to put them
>>>>> into mime64, pack that into XML, authorize and authenticate
>>>>> with an XMPP-server. doing the necessary presence stuff to
>>>>> finally send out a message or iq-stanza?
>>>> It sounds like your objection is to the use of XMPP more so than
>>>> its use of XML.  If you don't want (or need) XMPP's feature set
>>>> (discoverability, authentication, presence, security, etc) then
>>>> why would you use it to begin with?  If you do need that feature
>>>> set, then you're going to have to deal with the complexity those
>>>> features necessarily entail.
>>> In fact I like XMPP, mostly because it's an open standard and it
>>> got many concepts right and worked out (specified) well. What I
>>> don't like about XMPP is the XML part and the need for TCP but one
>>> can't have everything.
>> It sounds like you might want something like stanza.io with WebSocket
>> or BOSH. As a client-side API, neither XML nor TCP is absolutely
>> necessary these days.
> And it never was. I always could add another layer to get rid of the
> stuff below.

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


More information about the Operators mailing list