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.
Regards,
Alexander Holler
