This guy obviously hasn't actually used xmpp in real life. eJabberd does really weird things to us when we throw 300-400k messages at it a day.<p>And this:
"XMPP servers, which are essentially make or break an XMPP application, are rapidly maturing beyond instant messaging."<p>Have he ever tried to actually debug ejabberd? Cause it's very painful and time consuming.<p>Now, I'm not bashing xmpp, it's pretty cool, but it's not exactly "the next big thing", IMO.<p>We're actually abandoning it for AMPQ.
When I need to do something realtime, I connect users to my IRC server. Writing a client for IRC in Flash is very easy, I haven't tried with Javascript, I imagine you would use a keepalive connection somehow. Am I missing something by not using XMPP?
He's missing the main reasons why my company is going forward with a Jabber server: privacy and reliability.<p>We are a geographically distributed company that uses ICQ for a whole lot of communication, so when it goes down for any reason, work just about halts. Also, we routinely discuss very sensitive things (but we call each other if we need to discuss root passwords), so a dedicated eavesdropper could learn more than we'd like him or her to.
I think thats missing a big reason, google adopted it.<p>I have seen a resurgence of applications built on xmpp and instant messaging in general, I dont think a lot of people will know they are using xmpp, but it will be lurking in the back
So, I do think that XMPP will become a much bigger force given the (anecdotal) rate that post-college students replace their college email with Gmail (and get Google Talk with it). However, XMPP can't just rest. It really needs to get Jingle (their VoIP/video protocol) finished and approved and adopted. With more people looking to use voice and video online, they can't be left behind because of lack of features.<p>With Google driving some adoption and (hopefully) smaller IM networks seeing that XMPP would be in their interests (since it would help them overcome a lack of users), XMPP could see decent enough growth. However, if other networks have desired features that XMPP doesn't offer, the interoperability argument is countered by the lacking of things users want.
Once I get it working, I love it, but there's two problems I've always had with getting XMPP working from a programming/developing standpoint, both of which kept it from going mainstream sooner:<p>1) there were very few docs that explain the terms (roster, what a conference server is and why that is different from your regular connect server) in the context of other messaging protocols (AIM, for example). Yeah, I know now that "roster" is the equivalent of the buddy list, except it's not because there are operations that can happen on the roster and it's not complete clear which component maintains the roster and a lot of roster operations can happen asynchronously (due do its distributed nature) even when you're disconnected. None of this was obvious.<p>2) The docs that did exist, even for abstraction libraries, talked about creating XML stanzas and the XML stream and all the different XML namespaces (none of which were explained well enough to know when you would use 'em) and XML this and XML that. I don't want to write XML, I want to connect to a server and send and receive messages. That it is XML stream based is beside the point--and this was always touted as the reason that XMPP was so awesome, but we all know that it got caught up in the XML hype of the period in which it was conceived.<p>Eventually, libraries started being written that provided the correct level of abstraction for developers rather than protocol designers. Last one I used was Net::Jabber::Bot (cpan), which was okay, but there's still a lot of data extraction from partially cooked XML structures.