You're missing that they don't intend it as an RPC or REST interaction. It's to "stream" updates out of services, that can have multiple listeners.
This is already happening, but in isolated cases. Behind the scenes, Six Apart streams all the blog posts on its services directly to Google Blog search.
There are quite a few well-known services that get more API traffic (search engines, etc, pinging for updates) than actual human traffic. So something like this is ultimately necessary, whether it's XMPP or something similar.
I think they are aware of message queues, didn't they allude to them in the talk? Anyway they billed their talk as two guys who build web services making a tentative foray into the message-queue world, so if you think you can help, send feedback.
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.
This is already happening, but in isolated cases. Behind the scenes, Six Apart streams all the blog posts on its services directly to Google Blog search.
There are quite a few well-known services that get more API traffic (search engines, etc, pinging for updates) than actual human traffic. So something like this is ultimately necessary, whether it's XMPP or something similar.
I think they are aware of message queues, didn't they allude to them in the talk? Anyway they billed their talk as two guys who build web services making a tentative foray into the message-queue world, so if you think you can help, send feedback.