[Operators] Future of XMPP Re: The Google issue
chris at orr.me.uk
Tue Dec 3 18:56:10 UTC 2013
On 03/12/13 17:11, Alexander Holler wrote:
> 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). 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:
>> 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
> 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.
I understood your original message as being more about the code than the
data usage, but maybe you could clarify what you mean by overhead in
Sure, you need an XML parser for XMPP. You also need a TLS/SSL
implementation, zlib compression library, etc in order to communicate
securely and efficiently. At what point does the code required to
communicate become overhead?
More information about the Operators