After all these years, XMPP is still a PITA to implement.
Starting at the lowest level, XMPP streams are framed by the 2nd level elements in an XML document. Clients and server must keep an XML parser open for the lifetime of the connection. If you don't have a parser like expat available, then you either need to dedicate a thread to the connection or use ugly regex style hacks to handle the framing. Almost any other framing mechanism in use today would have been easier to use (null bytes between messages, length prefixed messages, and so on).
Moving up a level, the use of XML namespaces is over designed. XMPP uses unique namespaces for each type of connection (client to server, server to server, component to server). This provides no benefit to any party and is ugly for server developers where they need to deal with all types of connections.
I could go on. I have not even gotten to the application layer (RFC 3921).
Other protocols have warts, but not like those that I have encountered in XMPP.
I couldn't agree more. Too much namespacing. Also JSON would have been a much better encoding.
Recently wrote a bosh server in twisted/python and I find that even something that simple has scope for improvement. The specs for XMPP and BOSH are really badly written.
XMPP does have a lot of use (Google Talk, Facebook chat, Chrome browser sync, ...) and is the most successful non-proprietary instant messaging protocol.
I wonder what the state of the world would be like today if XMPP had been more approachable for developers. Would we still have instant messaging silos like MSN Messenger and AIM?
Apples and oranges. IRC is in general used for group-chat with topic channels, while other IM protocols (such as XMPP, ICQ, Skype, MSN, AIM, ...) are primarily 1:1 chats with friend/buddy lists.
That said, XMPP MUC (multi-user chat) is terrible, overengineered and less usable than IRC is.
(Disclaimer: I hacked on bits and pieces of XMPP client in Telepathy).
IRC is not proprietary and I did not say that it is. I think it's great that you are using IRC in your project.
Overall, there are many more active users of XMPP than there are users of IRC. When I say active users, I mean users who send and receive messages. I am not including users who only have the chat widget open on Gmail.
Earlier in this thread you estimate that GTalk and Facebook have 10% of the instant messaging market. Does IRC have more users than 10% of the instant messaging market?
Back in '99, I was working in the Instant-Messaging and Chat-On-Page sector. Let me tell you what I observed back then:
The IETF group working on IM was comprised of people from Netscape, Microsoft, AOL and a few others. At that point, AOL owned the IM world through AOL Messenger and (then recently acquired) ICQ. Microsoft was starting to make a dent with MSN Messenger after they started bundling it with the O/S and everything.
I was following the IETF discussions and mailing lists, and after a couple of months realised that the people on these lists had no reason to make things happen -- on the contrary. Everyone wanted AOL to open up the ICQ/AOL networks; they wouldn't. Everyone was already working on their own IM protocol, and didn't want to share it with the others -- they just wanted the OTHERS to share THEIRS. The discussions were long and pointless, revolving around semantics and irrelevant scenarios.
XMPP/Jabber developer was among the participants. The suggestions were full of flaws, complex and inefficient to implement, and no one liked them. But he was the only guy releasing code. And after a couple of years (sometime in 2001 IIRC -- I was no longer closely following it) it actually became usable.
It is still inefficient; it is still too complex for what it does; But for the last 9 years or so, it was the only option for a documented protocol with an open source implementation that you could find cross-platform clients for and install inside your own network.
Starting at the lowest level, XMPP streams are framed by the 2nd level elements in an XML document. Clients and server must keep an XML parser open for the lifetime of the connection. If you don't have a parser like expat available, then you either need to dedicate a thread to the connection or use ugly regex style hacks to handle the framing. Almost any other framing mechanism in use today would have been easier to use (null bytes between messages, length prefixed messages, and so on).
Moving up a level, the use of XML namespaces is over designed. XMPP uses unique namespaces for each type of connection (client to server, server to server, component to server). This provides no benefit to any party and is ugly for server developers where they need to deal with all types of connections.
I could go on. I have not even gotten to the application layer (RFC 3921).
Other protocols have warts, but not like those that I have encountered in XMPP.