[Standards] [Operators] Future of XMPP Re: The Google issue

Alexander Holler holler at ahsoftware.de
Wed Dec 4 21:21:48 UTC 2013

Am 04.12.2013 17:18, schrieb Ivan Vučica:
> Alright, since XMPP 2.0 was mentioned, here's a few thoughts on
> compatibility-breaking changes that would be scratching a few itches I have
> with today's XMPP. I've read about some of them elsewhere; sorry for not
> listing source material, as any reading I did was done months ago.
> In an XMPP 2.0, being encoded with XML should not be the first problem to
> solve. First problem to solve should be gripes large installations have
> when it comes to federation and load balancing.

I don't see a problem here.

> There aren't many servers with thousands of concurrent users behind a
> single domain, and it seems to me there is a good reason: it's not
> something supported by XMPP itself. Large installations have separate
> backend infrastructure which often uses different payload delivery
> mechanisms, unrelated to XMPP itself. I'm not familiar with what ejabberd
> does, but Facebook quite openly states that their internal servers don't
> speak XMPP.

Sure. I think nobody would use XML for internal protocols as it doesn't 
make much sense to do so. Why should one use the unnecessary overhead of 
XML for such things? It's like human editable configurations in XML, in 
my humble opinion the wrong thing to do. Fortunately it was only a short 
hype were configs for humans are done by new projects in XML. ;)

But I have a déjà vu here and think I've already read such a question 
some time ago.

I don't think clustering of XMPP-servers should be standardized. That 
depends heavily on the used backend (e.g. DBs and how they are 
structured) and the communication infrastructure between the clustered 
servers. So there is almost no common factor here.

> Finally, when implementing a client, we have XML namespaces and their
> inconsistent (or with some parsers hard-to-do) implementation. Namespaces
> are an awesome solution, but since they are not implemented completely
> consistently, XMPP 2.0 would have to ensure that their value is more
> obvious and better tested with a compliance suite.

I don't think there is a need for namespaces. At least not at the 
protocol side. How many attributes do exist for all namespaces? Maybe 
some hundred. So it wouldn't be a problem to spend e.g. 4 bytes where 
only the upper two or three are used by standards (and thus registered 
centrally) and everyone could be free to use the lower byte(s) (maybe 
except the 0) for "private" attributes. It's almost the same as 
namespaces, just a bit more simple.

> If XMPP didn't depend on some XMLisms like namespaces, it'd be easy to
> switch to a different transport mechanism, if someone prefers it. JSON?
> Plists? Protobufs? Custom binary? Doesn't matter. Whether XML is used is, I
> think, far from the most troublesome problem with deploying large XMPP
> installations and federating. If you want to scale, you have to use
> non-standardized solutions that are not supported by a lot of otherwise
> interesting server software.

The only problem I see with large installations, is when you want to use 
different types of servers. Then, of course, you need some standard 
inbetween them. But if all the servers are of the same type, there 
shouldn't be a problem there, as long as they support clustering at all.


Alexander Holler

More information about the Standards mailing list