Rob Kaye has written up what looks like a really interesting talk, but the comments sometimes highlight how badly understood XMPP is, and what the advantages are.
So a few, erm, meta-comments, and I apologise for really just spelling out what’s already been said.
First off, federation is key, here. It’s entirely possible to use XMPP as a purely internal message switch, but it’s probably not all that useful – at least, not unless you’re really aiming to make it external later. There’s good reasons for this, not least because although you could use a Javascript XMPP client in the browser and BOSH back to a single XMPP cluster, it’s far cheaper to just sling together a bespoke long-poll system yourself, using something like JQuery. That’s cheaper in terms of man months, infrastructure cost, and complexity.
However, if you allow users direct access to the message switch (via, as is suggested here, pubsub, or just via simple subscriptions and messages) then you’re doing “real” push, and in a way that allows user-defined access to those messages – basically, it’s like the HTTP “API”s, but on steroids. The web browser may well not be involved – and that’s okay, because it’s really not designed to do that kind of thing.
And that leads onto the second point – you *can* use HTTP to access XMPP, via BOSH, but you really don’t have to. BOSH is there when needed – and it does allow third parties to write web-based apps which can talk to your souped-up XMPP feeds – but when it’s not needed – like when you want to do a desktop app, or when you’re feeding into some other web app, or – well, almost anything you can think of.
