Version 1 by Pádraic Brady
on Jul 20, 2009 15:04.

compared with
Version 2 by Pádraic Brady
on Jul 20, 2009 15:06.

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

Changes (34)

View Page History
{info:title=New Proposal Template}
This page has been created from a template that uses "zones." To proceed:
{zone-template-instance:ZFDEV:Zend Proposal Zone Template}

# Edit the page
# Replace sample content within each zone-data tag with your own content
# Remove this notice
# Save the page
# When you are ready for community review, move this page to the [Ready for Review] section on the edit page.

{note:title=No placeholders allowed!}
Please do not create placeholders. Wait until you have sufficient content to replace all sample data in the proposal template before creating your proposal document.

{zone-template-instance:ZFPROP:Proposal Zone Template}

Zend_Magic Zend_PubSubHubbub
Alternatively: Zend_Feed_PubSubHubbub

[My Name|]


1.0 - 1 January 2008: Initial Draft.
0.1 - 20 July 2009

Zend_Magic is a simple component that reads my mind and generates code dynamically to do what I want.
h1. 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.

h1. 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.

h1. 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.

h1. 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).

* [Harry Houdini Wikipedia Entry|]
* [|]
PubSubHubbub Website
PubSubHubbub Core 0.1 -- Working Draft
PSH Page: "Why Polling Sucks"

Most requirements take the form of "foo will do ...." or "foo will not support ...", although different words and sentence structure might be used. Adding functionality to your proposal is requirements creep (bad), unless listed below. Discuss major changes with your team first, and then open a "feature improvement" issue against this component.
* MUST implement PubSubHubbub Core 0.1 -- Working Draft
* SHOULD implement any confirmed modifications to the protocol awaiting specification
* MUST implement support for Subscribers, Publishers and Hub servers
* MUST maintain a passing status when tested against the documented compliance test suite

* This component *will* correctly reads a developers mind for intent and generate the right configuration file.
* The generated config file *will not* support XML, but will provide an extension point in the API.
* This component *will* use no more memory than twice the size of all data it contains.
* This component *will* include a factory method.
* This component *will not* allow subclassing. (i.e. when reviewed, we expect to see "final" keyword in code)
* This component *will* only generate data exports strictly complying with RFC 12345.
* This component *will* validate input data against formats supported by ZF component Foo.
* This component *will not* save any data using Zend_Cache or the filesystem. All transient data *will be* saved using Zend_Session.

Zend_Crypt (potential)
Zend_Feed_Writer (proposed)
* Zend_Exception

The component is instantiated with a mind-link that ...
{html}<iframe src="" frameborder="0" width="555" height="451"></iframe>{html}

Describe some intermediate state of this component in terms of design notes, additional material added to this page, and / code. Note any significant dependencies here, such as, "Milestone #3 can not be completed until feature Foo has been added to ZF component XYZ." Milestones will be required for acceptance of future proposals. They are not hard, and many times you will only need to think of the first three below.
* Milestone 1: [design notes will be published here|]
* Milestone 2: Working prototype checked into the incubator supporting use cases #1, #2, ...
* Milestone 3: Working prototype checked into the incubator supporting use cases #3 and #4.
* Milestone 4: Unit tests exist, work, and are checked into SVN.
* Milestone 5: Initial documentation exists.

If a milestone is already done, begin the description with "\[DONE\]", like this:
* Milestone #: \[DONE\] Unit tests ...
* Milestone 1: Publish and have proposal approved with Zend comments to resolve
* Milestone 2: Complete initial component with unit tests
* Milestone 3: Complete/Maintain testing against the compliance test suite
* Milestone 4: Verify that code operates under PHP 5.3/6.0-dev
* Milestone 5: Complete documentation

* Zend_Magic_Exception Zend_PubSubHubbub
* Zend_Magic (factory class)
* Zend_Magic_MindProbe Zend_PubSubHubbub_Exception
* Zend_Magic_MindProbe_Intent Zend_PubSubHubbub_HubServer
* Zend_Magic_Action Zend_PubSubHubbub_Subscriber
* Zend_Magic_CodeGen Zend_PubSubHubbub_Publisher
* Zend_PubSubHubbub_StorageInterface
* Zend_PubSubHubbub_Notification

Others may be determined during development


... (see good use cases book)
Use cases are currently being drafted.

class Zend_Magic_Exception extends Zend_Exception {}

class Zend_Magic {
Skeleton Classes will be published as they are completed. Component will follow a Test-Driven Design methodology.