Why XMPP Will Be Huge Very Soon | Hacker News Reader

Why XMPP Will Be Huge Very Soon

intridea.com

52 pointsmbleigh40 comments

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.

And this: "XMPP servers, which are essentially make or break an XMPP application, are rapidly maturing beyond instant messaging."

Have he ever tried to actually debug ejabberd? Cause it's very painful and time consuming.

Now, I'm not bashing xmpp, it's pretty cool, but it's not exactly "the next big thing", IMO.

We're actually abandoning it for AMPQ.

I'd bet that early web servers, too, did some really weird things when web adoption started to snowball in the 90's. A protocol/paradigm's current state of implementation is not necessarily indicative of future progress and adoption. If anything, the fact that developers like you are building large-scale applications and discovering what breaks it is encouraging for XMPP's future.

XMPP is TEN years old! You'd sort of expect the software to be reasonably mature by now.

"eJabberd does really weird things to us".

Describe the weird things, please. I'm about to deploy ejabberd for a production site, and I'm interested in your experience.

XMPP is XML based and need heavy processing power (for e.g. not suitable for mobile platform) whereas AMPQ is a binary protocol.

http://www.deepdarc.com/2008/02/14/mobile-xmpp/

Keep in mind that the problems we're having aren't with XMPP, per se, just with ejabberd. Ejabberd worked flawlessly for several months until it started exhibiting some very strange behavior and performance characteristics. We upgraded to a newer version and we suddenly ran into another, different set of strange behaviors.

That said, word on the street is that ejabberd is the best implementation of an XMPP server. AMQP supposedly offers better reliability (with RabbitMQ) as well as a whole lot of pretty cool features that Jabber really doesn't.

Huge processor spikes which we think are caused by too many connections to a single room or user. We're not 100% sure because we can't replicate it in a dev environment and we don't really want to turn on debugging in a production environment, not to mention that debugging mode isn't the most helpful thing ever.

If you start it up in "live" mode (ejabberdclt live), we see "Replacing connection..." sometimes, which then throws a "Broken Pipe" error in our rails app. But again, we can't isolate what's happening there.

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?

>> "Am I missing something by not using XMPP?"

You're missing hours of headaches working through over-engineered ridiculously overly complicated horrible XML protocol. Stick with IRC ;)

I just coded a level file in XML for a game being developed in one of my classes. The same group member who was so adamant about coding the levels in XML had neglected to build an XML creation program. So there we were, trying to wade through > 10,000 lines of XML. I wanted to cry

FWIW, I've had a different experience with XMPP. Take for example XMPP Multi-User Chat (http://xmpp.org/extensions/xep-0045.html) - which outlines a rich set of interactions between occupants of a room - something I'm really glad someone else engineered for me. Plus, take a look at the XML stanzas (in the examples here: http://xmpp.org/extensions/xep-0045.html) you are sending to the server, they're really not that big or complicated. Lastly, with BOSH (http://xmpp.org/extensions/xep-0124.html) and incredible XMPP Javascript client libs like Strophe (http://code.stanziq.com/strophe/), the possibilities are pretty exciting for web apps.

A quick skim of the Multi-User Chat though... Firstly, it's 9 years old :/ why is everyone still not using it? Secondly, you can immediately tell it's ridiculously over-engineered.

  <field var='muc#roominfo_occupants' label='Number of occupants'>
    <value>3</value>
  </field>

Sorry, but you can't really look at that protocol and say it's not ugly and verbose beyond reason. The number of occupants in a room is surely used enough to deserve an encoding of less than 75 characters to specify a number.

Isn't that the whole problem with XML

Am I missing something by not using XMPP?

Identity and S2S federation. IRC is fine for a closed system, but XMPP's global namespace has a lot of potential for integration between different real-time systems.

Ok... now what feature that people need does that translate into? Honest question - I don't know much about the space.

Server-to-server means you set up your IM server, and I set up my IM server, and... drumroll please... they can actually talk to each other.

Remember when Prodigy users couldn't mail Compuserve users, or AOL users couldn't mail Usenet users? That's where IM is right now, held back by the fact that it consists of nothing but a series of closed gardens.

XMPP makes it work like email. Your JID looks like an email (and can also end up being an email identifier), and the servers know how to route amongst one another.

If you can't see how this might be a nice feature, it is only because you've become too used to the status quo to see.

Identity comes from the fact that your JID is now generally accessible from anywhere in the world, and thus your JID can be used as your identity, just as your email address can, and, like I said, they can even be exactly the same.

Further, since XMPP was designed to work this way from day one, it means that all other XMPP services work across servers this way. Presence subscriptions are correctly handled, one server can host conferences and people from other servers can participate, etc.

Integrating servers that are being used as message conduits between the front end and the back end of an application seems like a nightmare, security wise. I much prefer integration points to be limited rather than everything out in the open.

So you liked the prodigy solution better than email? Sure there was less spam.. but you couldn't talk to people

I'm not quite sure, but imagine something like webhooks but real-time. You could tell service A to ping service B over XMPP whenever something interesting happens; I think this would be harder with IRC.

Imagine a world where IM was more like Email... every company/org has their own server and everything else is just piping.

Think IPv6, or openID and you'll see what the feature is ;)

Funny, I heard the same argument years ago.

He's missing the main reasons why my company is going forward with a Jabber server: privacy and reliability.

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.

Why not just an irc server, with SSL and passwords etc?

Pidgin + OTR FTW

Solves the encryption problem, but doesn't solve the reliability problem.

Also, if your company needs to be able to log the IMs for compliance reasons, that doesn't solve that either.

(Disclaimer: I work for a company that builds IM servers for companies. But... the above isn't exactly controversial.)

You can still log with OTR, and if you use AOL/ICQ/MSN/Gtalk etc. there will always be at least one network still kicking.

unless your corporate network's internet connection is down...

Then you have bigger problems. I'd start with a reliable net connection if you want to do business online.

shit happens. being able to contact someone when it does is important.

i used to work for an isp and we had a private irc server that was very valuable in the case of outages when we needed to broadcast information to other departments. if i had to deploy it again now i'd choose an xmpp server, but either way, relying on an off-network communication server is not a good idea for a variety of reasons.

I think thats missing a big reason, google adopted it.

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.

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:

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.

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.

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.

Anyone know of any good XMPP implementations that lend well to implementing gateways? Preferably in C/C++?

Your question is somewhat vague and muddled. Could you clarify what exactly you are asking for? How are you using the term "gateway"?

Gateway is as is defined in RFC 3920 Section 2.1

"G1 = A gateway that translates between XMPP and the protocol(s) used on a foreign (non-XMPP) messaging network"

I don't think my question was not vague at all. It just might be out of the ordinary. Most people are interested in XMPP client implementations. I want a pre-existing open-source project that would be a good first step towards building an XMPP gateway.

OK, I wanted to make sure that you were indeed asking for that. While you are correct that "gateway" is well-defined, most of the time I see it, it is misused or used vaguely.

So, I can help you out. The only library that I know of that is designed specifically for the purpose of implementing gateways is Thrasher Bird: http://developer.berlios.de/projects/thrasher/ (git at http://repo.or.cz/w/thrasher.git ). I am the lead developer of that library. While the "sales pitch" is that it wraps libpurple, it is actually designed so that the "gateway" part of the library is separate from the "protocol" part of the library, unlike every other gateway I've seen.

It's in Perl, and it's still a bit alpha-ish, but it is also exactly what you are looking for and in active development, so you'll have to decide whether that meets your needs.

If you're interested in more information or need help, contact me at jbowers@barracuda.com . Compiling may be a bit of a chore, but I've managed it on a couple of different Linux systems now.

Actually, now that I think about it, the only thing the C code is there for is libpurple support; it's all Perl and there's no compilation you'd need to do at all if you don't want to use libpurple.

http://code.stanziq.com/strophe/ is probably a good start.

Unless I'm missing something totally obvious, many of these reasons might as well be said for SIP.

Reply on news.ycombinator.com