[Operators] Future of XMPP Re: The Google issue

[Solomon Peachy]

On Tue, Dec 03, 2013 at 05:11:38PM +0100, Alexander Holler wrote:
> 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.

Except the XMPP implementation is relatively minor when you consider 
that you already have to have (for example) a full 802.11 protocol stack 
(including WPA and WPS), full TCP/IP stack (including DNS, DHCP, etc), 
not to mention TLS, zlib, and more before you can do anything meaningful 
across the public internet.

That's a lot of code that has to JustWork(tm), and adding an XMPP client 
(or server!) is just another component.  Any of these compoents could 
have any number of bugs lurking.

However, in general, XML parsers are actually pretty low risks in due to 
their maturity, but like anything else, a good way of reducing risks is 
to use a pre-existing library implementation that's already seen a lot 
of real-world testing.

But on a more systems-level, you don't trust your software to just work, 
you add in watchdogs so that you catch unknown failures and recover 
cleanly.

But I digress.

Sure, you could replace the "XML" part of XMPP in favor of a binary 
stream (yay, ASN.1!) but XML parsers are mature and robust at this 
point, or at least far more robust than writing something from scratch 
(especially if it has to support arbitrary data!)

The same goes for the rest of XMPP; its overall design and capabilities, 
how clients and servers interact, and so on -- you'll end up 
re-implementing the wheel and probably end up with a much lower quality 
(and less-capable) system to show for it.  (One could argue that Google 
Hangouts is an example of this principle...)

I'm not saying XMPP is perfect or suitable to all situations, but its 
use of XML as its low-level transport goes a long way towards enabling 
XMPP goals of extensability, interopability, and robustness.

 - Solomon
-- 
Solomon Peachy        		       pizza at shaftnet dot org
Delray Beach, FL                          ^^ (email/xmpp) ^^
Quidquid latine dictum sit, altum viditur.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/operators/attachments/20131203/4fd1e894/attachment.pgp>