[Operators] Future of XMPP Re: The Google issue
Solomon Peachy
pizza at shaftnet.org
Tue Dec 3 19:39:23 UTC 2013
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>
More information about the Operators
mailing list