<h2>How Hubbub Works</h2> There are three parties in the Pubsubhubbub model. There's a Publisher (FeedBurner, for example), and a Subscriber (perhaps Netvibes) and the communication is facilitated through a Hub (Google's AppSpot Hub is the demo and most popular Hub so far). The publisher knows that every time new content is published it's going to notify the Hub - the Hub that gets notified will be declared at the top of the publisher's document, just like an RSS feed URL. So the Publisher delivers new content to the Hub and then the Hub will deliver that message immediately to all the Subscribers who have subscribed to recieve updates from that particular publisher. This is very different from the traditional model of a subscriber polling a publisher directly every 5 to 30 minutes (or less) to check and see if there's new content. There usually isn't and so that model is inefficient and slow. Hubbub is nearly immediate and only takes action when something important occurrs. It's remarkably simple, at the end points in particular. If things ever get complicated it's in the Hub and that's easily available as a service if a publisher doesn't want to host their own. - Marshall Kirkpatrick

That's good! - Julien

awesome, thanks. - Marshall Kirkpatrick

Great, although Brad's kid in the backseat analogy rules. - Darren

yes, incorporating that explanation as well, thanks - Marshall Kirkpatrick

very clear explanation. spot on. - Josh Fraser

Awesome. Thanks, Marshall! - Amber Case

Pretty good. For context, I think it's important to point out that the hub in PuSH is acting as a relay. The relay is necessary largely for scaling purposes — that is, it plays a very important role, but the technology underlying the hub is extremely simple. - Chris Messina

A better example publisher would be ReadWriteWeb, rather than FeedBurner (which would likely turn into a hub itself). Let's say RWW posts a new blog post; the blogging software then pings any number of hubs with a message: "Hey, new content here". The hub says, "Great thanks," grabs the content, and then *pushes* the content to everyone on its "subscriber" list. - Chris Messina

RWW could send out those notifications itself, but it would be highly inefficient. It's better to have a hub handle and route all those notifications since that's *all* it would be doing. - Chris Messina

And, it's also not unlike SMTP ("simple mail transport protocol"). The difference is that it works over Port 80 using HTTP ("hypertext transport"), which means that you can effectively "send message to URLs" — not just email accounts! Thus, http:// status.net/chrismessina could send a message to http://twitter.com/marshallk. - Chris Messina

Chris, you're making it sound even more interesting than I was aware of. - Marshall Kirkpatrick

Marshall, I agree with you on this. Chris is indeed opening our "third-eye" on the range of use cases for this. It is a powerful "atomizing" protocol delivered with very simple underlying technology. I've been looking at XMPP, AMQP & a Comet-derivative for an application that may now be accomplished quite simply via PubSubHub / PuSH. It would also be great if Chris could also get Jyri to comment over here with his views. - http://twitter.com/AAinslie - Alexander Ainslie