Table of contents
Pubsubhubbub How? Why? Now? (1I)
Convener: Pubsubhubbub Guys
Notes-taker(s): Michael Calore
A. Tags for the session - technology discussed/ideas considered:
B. Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps
PubSubHubbub is a machine readable way to upgrade from polling to real-time.
a simple publish/subscribe protocol.
brett slatkin and brad fitzpatrick from Google
slowly adding support to the feeds on all of Google's properties.
decentralized by design. no one company in control
history:
real time notifications were broken. polling the crap out of every
service on the web wasn't scalable. we needed a way to solve discovery
and subscription together
why another protocol?
current specs weren't sticking.
XMPP is an existing standard, a decade old, but not widely used
outside of IM. other standards are too complex, not pragmatic.
"i don't like it when specs get huge by adding tiny features to make
one person happy" -- bradfitz
therefore: Pragmatic, not theoretically perfect, solves huge problems
and use cases with minimal effort.
any complexities get pushed towards the hubs.
also, hubs can set their own policies on transformation. whatever
extra sauce the hubs want to provide -- translating feeds into
English, serving the last 5 posts to provide sub with some feed
history regardless of the age of the original posts, etc. -- is
possible. hubs can run their own feeds and do their own content
filtering, speed-ups, etc in house. the spec stays clean, and subs and
pubs get what services they want.
<snipped from the wiki>
The protocol in a nutshell is as follows:
* An feed URL (a "topic") declares its Hub server(s) in its Atom
or RSS XML file, via <link rel="hub" ...>. The hub(s) can be run by
the publisher of the feed, or can be a community hub that anybody can
use. (Atom and RssFeeds are supported)
* A subscriber (a server that's interested in a topic), initially
fetches the Atom URL as normal. If the Atom file declares its hubs,
the subscriber can then avoid lame, repeated polling of the URL and
can instead register with the feed's hub(s) and subscribe to updates.
* The subscriber subscribes to the Topic URL from the Topic URL's
declared Hub(s).
* When the Publisher next updates the Topic URL, the publisher
software pings the Hub(s) saying that there's an update.
* The hub efficiently fetches the published feed and multicasts
the new/changed content out to all registered subscribers.
The protocol is decentralized and free. No company is at the center of
this controlling it. Anybody can run a hub, or anybody can ping
(publish) or subscribe using open hubs.
</snip>
additional notes on functionality:
* adding anything semantic to the feed, hubbub will just pass along blindly.
* right now it's just for public feeds. OAuth-supported private posts
will have support by 1.0
* also right now, hubs will just spool updates upon failure. Google
spools about 10 or 15 minutes before giving up.
* also coming in 1.0: single payloads for content aggregation.
subscribers can option in to what max size their payloads should be
and the hubs will cache and deliver -- works well for subs with
flakier connections or narrower bandwidth.
* stats support -- hubs will eventually be able to supply stats for
feed consumption, etc.
current usage/management:
100 Million feeds enabled.
livedoor, sixapart, superfeedr, lazyfeed,
Socnode, Reader2Twitter, chat gateways
hub code available for: Perl, Python, Ruby, Java, Haskell... (many)
spec is licensed by the Open Web Foundation
different than RSScloud. there was political discussion about this.
slides, info on the code project site
Comments