Text based protocols may seem easy but often leads to unnecessary complexities. For the sake of human readability, protocols that start out simple at first eventually gets bloated and overly complex. Just look at the WS-* protocol stack if you want an example. And not to mention characters being garbled because the creator of some homepages didn’t bother to define the charset.

While we have problems like endianness in binary communications, text encoding is no simpler and can also be ambiguous which causes hidden headaches and sometimes nasty security holes too. I guess you must prefer something which seems easy at first but is hard to validate until runtime. Script kiddie mentality.

The reality is that XMPP is already there, it is not bad and better than other existing ones.

I have deep experience about XMPP and Google Protocol Buffer.

Posted 17 January 2008
http://florianjensen.com/2008/01/17/aol-adopting-xmpp-aka-jabber/

Posted 14 May 2008
http://saunderslog.com/2008/05/14/facebook-annoints-xmpp-open-im-endgame-in-sight/

Don’t feel bad, I was thinking this was new. I wonder what FB is waiting for.

Arguments in XMPP’s favor are clearly:

1) Ease of implementation
2) Extensibility
3) Interoperability.

The interoperability one due to existing implementations is a bit of non-starter if we’re talking about pure protocol design.

Ease of implementation and extensibility, however, are clearly huge wins, and I really see them as XMPP’s primary advantages. With the advent of things like Protocol Buffers and Thrift, however, this picture changes drastically. If Facebook or Google released messaging and presence protocols built on Thrift or Protocol Buffer message objects, you’d get:

1) Far smaller messages than XMPP
2) Forwards and *backwards* compatibility of all messages (which I don’t think XMPP supports?)
3) Easier implementations than XMPP in every major programming language because all the tricky code is generated.

The result would be clients and servers that just work better from every angle I can think of save interoperability with clients and servers out there now. They’d be *way* faster. Their code generation in particular is amazing – you’d literally just have to decide the message formats, and you’d have implementations in every major language with one command (save some extra steps with creating the RPC layer with Protocol Buffers).

Granted, this is a slight diversion from my original argument, but it’s simply astounding what those tools open up in terms of what’s possible to do with minimal effort.

Anyway, I unfortunately don’t have time to hop on the IETF lists these days, but I think something along those lines would just be super slick and cool (in a really geeky sort of way).

Best of luck Dave!

-Adam

No, Peter’s first point was that XML was one of the very few tools available to build something like XMPP at that point in time. The other obvious tool would have been ASN.1, which wasn’t popular at the time, especially in the open-source arena from whence Jabber grew. As it happens, XER/PER comparisons allow us to have some idea of the difference, there, and it’s not that compelling, compared with zlib or EXI.

Re-encoding the existing XML schema into some serialized form other than XML itself is indeed possible, but it’s tricky to achieve the same flexibility, since XMPP essentially assumes that virtually anything can be extended. As far as any serious experimentation has thus far found out, nothing outperforms simple zlib with sufficient efficiency to be worthwhile. (EXI is an example of something that does help, but is sufficiently complex that nobody can be bothered).

Skype and RTMFP, being both proprietary protocols, don’t make for good examples here. Skype and Adobe tightly control not only their use, but their applicability, whereas the XMPP community leads the applicability of XMPP by example. In addition, Adobe and Skype really don’t care if their protocol is easy to understand, and – certainly in Skype’s case – they appear to aim for the exact opposite.

XMPP, on the other hand, has to be very much easy to learn and work with, and experience has shown time and time again that a human-readable syntax really helps to get multiple interoperable implementations. When I said that text-based protocols hold sway at the IETF, I meant that in the RAI and APPs Areas in particular you’d have to work hard to convince people that the benefits of a compact binary protocol outweigh the disadvantages.

Consider, for example, LDAP. It’s ASN.1/BER, for the good reason that it derives from X.500. There are surprisingly few servers, and most of these are so incestuously related, there’s arguably only really UMich and Quipu, and even being generous, no more than a dozen over all these years. LDAP also never achieved the goal, and has settled into a fairly constrained niche.

XMPP, on the other hand, has several implementations inside a decade, including by Microsoft, Google, Sun, and now Facebook. It’s had various levels of support from Oracle, Cisco, Yahoo, and AOL – in fact, it’s hard to find any serious company actively avoiding XMPP, now. I suspect a lot of this interest can be boiled down to the protocol being understandable and easily extensible, and both of these in turn owe a lot to there being a human readable syntax.

So your argument is, basically, that XMPP would be more efficient for specific tasks had it not been written using XML, and instead written using some binary schlock.

Well, I agree with you, in so far as that argument goes. But I think that protocol efficiency is not the primary goal – interoperability and deployment is, and XMPP has them in spades – so I think it’s self-evident that XMPP is a success, and whilst it might not be the most efficient design possible, that’s outweighed vastly by it being one of the most easily implemented.

But yeah, do hop on the XSF’s Standards list, and help improve the efficiency – there’s a load of people who’ll welcome the input – and both Peter and I will be amongst them.

Oh, and FTAM really is better than HTTP. But only because *anything* is better than HTTP, it’s a real crock of a protocol.