Ask YC: Why the excitement over XMPP on the backend?

"Stateful XML protocol" makes complete sense, it just isn't very informative. It describes a protocol that is both stateful and XML-based. Those are independent attributes of a protocol; obviously, you can have both stateful non-XML-based protocols and XML-based stateless protocols, but I don't see why the OP's statement is nonsensical.

Totally agreed. That doesn't negate anything I just said. It's stateful. It's XML. It's a stateful XML protocol (and it happens to also have presence, which I left out, but does make some people's knickers wet).

XMPP pierces NAT for one reason. This means you can have XMPP clients behind many more firewalls then you can with amqp.

Also xmpp libraries are available in almost every language and platform and traditional MQ's do not have presence or federation(ie horizontal scalability).

It's not about using XMPP as a message queue per say. It's about using xmpp as a p2p messaging system for machine to machine communication as well as integration with chat.

Is there any existing MQ system that is decentralized? I said "may works better" because it is a conjecture limited by my ignorant mind. Internet is essentially decentralized. So if any MQ system can be modified to worked in decentralized environment. Then they may work better than XMPP. I believe the performance of throughput of those system may be higher than XMPP.

On the other hand. If I only have an internal cluster, I will choose to use existing MQ system instead of XMPP. I may want higher throughput, and I don't care authentication of endpoints because they are all trusted. Why do I need all the extra stuff that XMPP demands?

Regarding the case I mentioned in PubSub: It was just an idea. In fact, I was the one who mentioned the idea then. And our CTO and VP of Eng thought it was an interesting idea because in this case, we just wanted to see how does it work out and did a test implementation. And it was pretty flexible for us to use it.

Of course XMPP is not the first MQ system on Internet. SMTP is the first one, right? In SMTP, we don't know anything of endpoints. We assume senders and recipients exist and are taken care of by SMTP servers. I think in XMPP, because the original application is chatting, then it adds an new protocol to notify "presence" of endpoints.

Edit: I think when I said "internet scale", I actually meant "a system of billion nodes that are loosely coupled together"

Federation.

I read a bit over ActiveMQ, RabbitMQ, and the recent and lovely ZeroMQ. As far as I could find, none of them provide federation on a Internet scale. Specially Open Federation using TLS.

I'm a XMPP developer for 6 or 7 years now, and if someone thinks that XMPP is going to replace MQ systems, they are delusional. But for Web integration, XMPP beats the crap out of current MQ systems because of Federation.

Sure, you can get 2.5M messages/sec on ZeroMQ. So what? I've seen personally a XCP XMPP server doing 1M messages per second also. But for internet scale stuff, even slower servers like OpenFire would work just fine for the current loads they are seeing.

It also helps that for scripting languages commonly used (like Perl, Ruby, Python), XMPP bindings are commonly available, while AMQP are still rare. Please please prove me wrong :).

My recommendation for startups? Use a MQ system internally from day one to develop your solution, but use XMPP to talk to the outside world.

RabbitMQ (and I'm suggesting it based only on what I read, I don't use it myself, I use another one) is the best placed MQ system right now, because it offers the bridge between local MQ system and XMPP world.

Best regards,

It is pretty common for a RESTful protocol to end up with batch-fetching and batch-updating operations. Once you add those operations, you've already violated the "uniform interface" constraint and removed all the benefits (primarily caching, authentication, authorization, and parallelism) that derive from the uniform interface constraint. Once you have batch-fetch and batch-update, those two operations can generally do everything that you usually did via individual PUT/POST/DELETE operations. So, why do you need the separate PUT/POST/DELETE operations at all? It is just more surface area for you to maintain.

Now, maybe you want to combine your batch-update and batch-fetch operations into a single "batch-update-and-fetch" POST operation. Well, that is exactly what WS-* does.

On the flip side, sometimes instead of batching you want to fetch or update only parts of individual resources via some extension to partial GET requests and or a PATCH method. There is currently no uniform interface for those so, just like in the case of batching, you lose all the uniform-interface benefits.

Now, let's say you want to combine your partial-resource operations with batch operations over multiple resources to reduce the number of requests you receive and/or the reduce the aggregate size of requests, so you add the ability to do patching and partial-fetches to your batch-update-and-fetch mechanism.

Now take a step back. Doesn't your batch-update-and-fetch-with-patch-and-partial-fetch look a lot like SOAP with WS-ResourceTransfer? It will probably look a lot like SOAP; not even the newish SOAP 1.2 that actually is somewhat HTTP cache friendly, but old school RPC-only SOAP + WS-ResourceTransfer.

Look at Google's GData and OpenSocial's RESTful API for examples.

And, that is totally ignoring anything to do with transactions.