compared with
Version 3 by Pádraic Brady
on Jul 30, 2009 12:20.

This line was removed.
This word was removed. This word was added.
This line was added.

Changes (5)

View Page History
Alternatively: Zend_Feed_PubSubHubbub

h15. What is PubSubHubbub?

PubSubHubbub is a Publisher-Subscriber protocol which operates over HTTP using REST. Its purpose is to allow consumers of RSS and Atom feeds to subscribe for updates to a Hub Server for any specific feed. This Hub Server will usually be notified by the publisher of that feed whenever an update in the feed occurs. In turn, the Hub Server may then notify all consumers that an update has occurred by making a request to a URI provided by the consumer, with an Atom/RSS feed containing the updated or new feed entries in the request body. This protocol therefore implements a push system whereby updates are pushed to the consumers in real time (within reason). This is opposed to the current prevailing practice where consumers must frequently poll a publisher's feed URI to check whether any changes have occurred. This imposes a time delay between a publisher making a change and any consumer noticing and retrieving it. The benefits of the push model therefore obviously lie in the immediacy with which consumers can distribute new content to their visitors/users.

h15. PubSubHubbub Specification Status

The PubSubHubbub protocol is not a finalised one. Indeed it is constantly evolving, and this proposal takes that evolution into account using as its basis the current PubSubHubbub Core 0.1 -- Working Draft and its reference implementations. As with a number of open specifications in recent years, waiting for a final and stable specification has not prevented the continued rise of implementations and real world use cases. To date, PubSubHubbub has been implemented (publicly) by SuperFeedr and FeedBurner so the protocol is in use right now. There is little justification in holding up adoption when adoptions are already present and PubSubHubbub services are being offered to the public. The specification will evolve over many months, but this is to be expected. Indeed, this reflects experiences with specifications like OAuth which saw widespread adoption and use in the wild long before a final specification was published. Granted, the risk of not becoming a mainstream protocol remains but the progress to date is encouraging.

h15. Technical Details

It's actually quite difficult to make PubSubHubbub sound technically complex. It's a simple protocol using a web-hooks system (i.e. allows you to subscribe to another site's events using a URI), a coordinating Hub Server (which can be anyone since this is a decentralised system - you could be your own hub for all PubSubHubbub cares), and the exchange of simple Atom formatted notifications or messages between all parties. Atom is used here as the notification system's substrate which should be distinguished from the feed resources whose updates are of interest and which can be either Atom or RSS.
The remaining technical details concern the protocol's operation over HTTP (nothing special), the discovery of the various URI endpoints (e.g. how consumers locate the Hub(s) servicing a feed so they can subcribe for updates using that Hub's endpoint URI), and security considerations (for future specs) such as accessing private feeds and ensuring the integrity of messages being exchanged by two parties. Anyone with a passing familiarity of OAuth or OpenID would not be out of their depth since these other open protocols deal with similar topics.

h15. Implementation Details within Zend Framework

The Zend Framework as of version 1.10+ should (assuming successful reviews) package within its stable release an assortment of components which were designed to support a vastly simplified means of reading and writing RSS and Atom feeds, the latter targeting Atom as a general web service substrate. Also included should be the Zend_Crypt component introduced in support of Zend_Oauth. With these three components, implementing PubSubHubbub should be fairly simple. The only real work would be in orchestrating the protocol workflow from the perspective of different parties. For example, we can assume there would be a Zend_PubSubHubbub_HubServer class to implement a Hub Server. In a similar vein, we can also assume the presence of Zend_PubSubHubbub_Subscriber and Zend_PubSubHubbub_Publisher for the remaining two parties in the overall protocol. Adding a storage medium to any party can be supported by Zend_Cache and/or Zend_Db (an interface should be defined so Zend_Db remains optional).