[Operators] Future of XMPP Re: The Google issue

Alexander Holler holler at ahsoftware.de
Tue Dec 3 16:11:38 UTC 2013

Am 03.12.2013 15:11, schrieb Matthew Wild:
> On 3 December 2013 08:11, Alexander Holler <holler at ahsoftware.de> wrote:
>> Am 02.12.2013 18:50, schrieb Peter Saint-Andre:
>>> On 12/1/13 4:34 AM, Andreas Kuckartz wrote:
>>> It is possible that XMPP will be used mainly for enterprise IM inside
>>> organizations, and for things other than person-to-person chat (there
>>> is a lot happening these days with machine-to-machine communication in
>>> the broad sense), whereas person-to-person chat will happen using
>>> other technologies (IMHO likely p2p, not a decentralized server
>>> model). But my crystal ball is not 100% accurate. ;-)
>> Hmm, I wouldn't want the overhead of an XML-streaming parser for M2M.
>> Also XML makes it very easy for humans to read and debug the
>> communication, a streaming XML-parser isn't that ideal for M2M.
> I can't believe that it's the end of 2013, I can play multiplayer 3D
> games with realistic textures smoothly in my browser over a
> low-latency fibre-optic connection direct to my home, data centres now
> internally have 1, 10, or 100 Gigabit links, and people are STILL
> complaining about the "overhead" of XML (quoted because nobody ever
> seems to provide numbers to back up this statement[1]). And if we're
> talking about low-power embedded devices, even the latest Arduino
> boards run Linux now.
> I'm quite sure binary protocols will always have a place, but they
> rarely provide the features that XMPP has that are attractive from a
> system architecture perspective. Solving things like authentication,
> identity, federation, service/feature discovery and trivial
> extensibility - these are hard things to do, and XMPP has done them.
> Weigh this against the "overhead" of XML and it is a very minor
> concern for most applications.
> Also don't forget EXI, which turns XML into a small binary format too:
> http://xmpp.org/extensions/xep-0322.html
> I'm not saying that XMPP is the best fit for all M2M applications, but
> I definitely don't agree that it's inherently a poor fit either as you
> suggest.

Sorry, but you just missed my point. I haven't written anything about 
traffic or bandwidth, the problem is the need for the parser itself.

So I didn't mean traffic or bandwidth overhead, but code overhead.

Writing and verifying the correct operation of an XMPP-server is 
anything but trivial. And M2M is something where usually no admin is 
around which can restart a server or even fix bugs.

Alexander Holler

More information about the Operators mailing list