Real-Time Web Protocol PubSubHubbub Explained
Real-time web protocol PubSubHubbub's co-creator Brett Slatkin, an engineer at Google, gave a talk at Facebook headquarters today about how the new information delivery system works and how Facebook can support it.
He's published his deck on his blog and we've embedded it below as our Real-Time Web Article of the Day. If you're interested in making your content available in real time or more efficiently using real-time content syndicated from elsewhere, this presentation is a must-see.
Each day leading up to the ReadWrite Real-Time Web Summit on October 15th we're highlighting one important article written by someone from outside our staff on the topic of the real-time web. Slatkin's 61-slide deck makes a great introduction to both the technical and strategic aspects of the PubSubHubbub protocol.
Slatkin starts out by explaining the value propositions of real-time data delivery, with an emphasis on social networking because he's speaking at Facebook. He then goes on to discuss how PubSubHubbub works and how to implement it. He also spends several slides discussing what he considers the technical shortcomings of other real-time protocols, particularly RSSCloud, but that's only a small part of the talk.
Slatkin will be participating in the Real-Time Web Summit next month. ("Foo-style [unconferencing is] always way better than talks," he said last week "See ya there!") He's got a very big vision of where all this is going to go; he's thinking of things like distribution of financial information and data from sensor networks in the physical world. This isn't just about social networking, and it certainly isn't just about Twitter, though that's what most people tend to think of when they hear the phrase real-time web. There's a whole lot more to it than that, as you can see from the list of questions some of our event participants have already said they want to discuss.
Here's what Slatkin has to say, a few of our favorite early slides are excerpted above the embedded slideshow in order to convince our subscribers to click through to the site and read the presentation.
What is PubSubHubbub?
Some of the Benefits
It's hard to explain "flow," of course - you know it when you see it. Others in the industry have described increased time-on-site for website visitors, or a more human and people-centric experience of the web.
The list of possibilities is endless and Slatkin encourages developers to "scale up to new use cases" - meaning that building real-time to scale will enable new activities that we can't imagine yet.
On Decentralization and Design
Those are just a few of our favorite slides, below is the whole presentation embedded. Please check it out and consider joining us at the ReadWrite Real-Time Web Summit to discuss this and other real-time technologies and their implications.
ShareRelated Entries
1 TrackBacks
TrackBack URL for this entry: http://www.readwriteweb.com/cgi-bin/mt/mt-tb.cgi/13008
Facebook
Comments
Subscribe to comments for this post OR Subscribe to comments for all ReadWriteWeb posts
"...It's hard to explain "flow," of course - you know it when you see it."
Live example of "flow" which may or may not be using PuSH: http://twistori.com
BTW what's it going to take to drop PubSubHubBub and use PuSH? Real time web demands two syllables or less. Might as well name the next useful real use bit that gets us where we want to go: Supercalifragilisticexpialidocious
What is 'Bub' ?
And, how is all this different from IBM WebSphere MQ Publish/Subscribe ?
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.amqnar.doc/amq6246.htm#amq6246
Thanks for posting. We're definitely working this model into CloudProfile both for content updates and more generally (Engagement Stream, Radar, etc.). The machine learning part of me (http://bit.ly/vYfam)gets really excited about the possibilities with this.
Hey Marshall thats its really an fantastic stuff.. I like this stuff because here i get good information which is very helpful for me..
I can understand pushing everything through a hub to establish the connection, but it seems unless you also allow peer-to-peer connections, latency is going to kill you.
While even I agree that Push is a more elegant design than Pull, the conclusions that people draw about RSSCloud are really not huge concerns.
Modern virtual storage systems like S3 make the "thundering herd" issue easily surmountable.
What large scale publisher that needs to be concerned about spikes in traffic is willing to have a Hub deliver content to it's subscribers, but not allow Amazon or Google host it's RSS file?
And for the small guys, it's just not a concern either.
Matt: What you said only makes sense if: 1) You don't care about latency; 2) You assume RSS traffic won't grow significantly; and 3) You don't want to enable new uses of RSS.
No, Brett. It makes sense for one other reason. The concerns aren't causing anyone any problems, RIGHT NOW (not yelling, just emphasizing. Okay, slightly raising my voice.)
When it becomes an issue and we can't solve it, I'll buy you dinner and say, "you were right." ; )