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 <[email protected]> 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.
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
this case?
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?
Regards,
Chris
