I have a few proposals with Zend Framework. I also have an established record of not finishing them very reliably, yay! Ok, so that’s not a good thing. I seem to have established a weird tradition of finding myself in just the right scenario at the completely wrong time to hold me up. Luckily (it’s a bit like thinking THIS year will see a real Summer in Ireland), I do have oddles of time to burn right now. The ZF book is finally climbing Reboot Hill (the translated versions are progressing, and I will get to the next chapter soon – lots happened in the ZF since the drafts were written). Zend_Feed_Reader is in the ZF trunk, and definitely will be in 1.9. Zend_Oauth has been reviewed by me and patches are incoming in the next day to finish it (that should make it’s way into 1.10 along with Zend_Crypt).

Before this all goes sour and I a) wind up hospitalised after a freak accident involving Stephen Fry running me down while sending a Tweet on an iphone, b) see Eircom attacked by mysterious hackers intent on the downfall of Brian Cowen because he shows his appreciation for free speech by introducing legislation with the new criminal act of “blasphemy” defined or c) I’m abducted by Kerrymen (just because…well…they’re all mad down there), I’ve started pounding frantically on my keyboard for a new proposal called Zend_Feed_Writer.

ZFW is the counterpart to Zend_Feed_Reader (as if that wasn’t obvious). It’s purpose is to, once again, offer an alternative to the current Zend_Feed component using similar principles to those applied in Zend_Feed_Reader:

1. Use a simple, intuitive and limited API to eliminate guesswork and uncertainty.
2. Utilise PHP’s DOM to handle the complex internal construction of feeds.
3. Adhere to standards: RSS 2.0 (based on the RSS Advisory Board 2.0.11 spec) and Atom 1.0 (RFC 4287)
4. Behind the scenes, implement support for commonly used RSS/Atom modules like Dublin Core/Slash/Atom Threads
5. Allow users to implement/register Extensions (i.e. plugins) to add support for other modules
6. Liberally throw tests at every conceivable (including the possibly insane) scenario for use.

Just like Zend_Feed_Reader, there is obviously a question mark. Do we even need an alternative to Zend_Feed? ZFR had the major advantage that it was conceived of not only as a major simplification making developer’s lives significantly easier, but also as something that understood feeds – it was able to sift through numerous alternatives for commonly queried data points until it found a match, removing the need for developers to take on that role with custom abstraction layers and interpretive work. Zend_Feed_Writer does something similar, only in reverse. It creates feeds based on the most commonly inputted data points which contain the most logical or specification defined elements. It removes the guesswork, the need to cram up on the RSS/Atom standards, the specifications and the specs for all the different modules used. It eliminates work – and that’s always been the main goal. If you want to learn a bit more – look at the Zend Framework 1.9 Preview, and compare the documentation for Zend_Feed with that for Zend_Feed_Reader. It should highlight where both diverge in a meaningful way.

I’m currently drafting the Zend_Feed_Writer proposal over at Zend_Feed_Writer – Padraic Brady.

Which brings us to upcoming proposal number two, the colourfully named Zend_PubSubHubbub! Or Zend_Feed_PubSubHubbub depending on which name is most appropriate.

To explain, PubSubHubbub defines a protocol where any subscriber (that’s you) can subscribe to a hub server which notifies you when any feed you want to follow has changed. Wait for it… Publishers, the origin of the RSS/Atom feeds you want to follow, can then notify their hub server which in turn notifies you. It’s a push system. Publisher adds new content, and notifies Hub immediately. The Hub can then push the update to you right away. There is no polling every 30 mins for new content – it’s delivered to you, or you are told where to fetch it from, right away. It eliminates the delay between source and polling, the lack of which has given services like Twitter a major advantage in getting news/articles/videos out to hundreds of people almost instantaneously and seen traditional feeds lose some of their attraction. As the PubSubHubbub team put it:

A simple, open, server-to-server web-hook-based pubsub (publish/subscribe) protocol as an extension to Atom.

Parties (servers) speaking the PubSubHubbub protocol can get near-instant notifications (via webhook callbacks) when a topic (Atom URL) they’re interested in is updated.

The protocol in a nutshell is as follows:

* An Atom URL (a “topic”) declares its Hub server(s) in its Atom XML file, via . The hub(s) can be run by the publisher of the Atom, or can be a community hub that anybody can use. (RssFeeds are also 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.

Note, while Atom is prominantly mentioned – the protocol supports RSS also (be kind of stupid if it didn’t!). Atom however is a basic unit in its operation, just like it’s an excellent basic unit to utilise in any web service dealing with collections of items defined in an XML syntax.

The reason a PubSubHubbub proposal is interesting to me (besides always being game for a challenge) is that like OpenID and OAuth, it’s another decentralised open protocol that operates over HTTP. Also, the basic units are already or will soon be implemented/released! Zend_Feed_Reader (ZF 1.9), Zend_Oauth (ZF 1.10), Zend_Crypt (ZF 1.10) and Zend_Feed_Writer (ZF 1.10 with a little luck). Putting the protocol on top of those ready to go components will save a lot of time and effort at the end of the day.

To be honest though, I have a few doubts on this one because PubSubHubbub is so new that it is only starting to seep into implementations in the wild. So getting it into the Zend Framework right now might not happen – as an early first spec its implementation will be continually evolving/growing over many months). I’ll what a review brings from the community once the proposal is written up this week.

That said, a week ago the spanking brand new PubSubHubbub Core 0.1 Specification (July 8, 2009) was implemented in at least one meaningful way – initial support has been implemented in FeedBurner. Then we have a WordPress plugin in progress, and several reference implementations including the for Google App engine. Still early days though. Of course, PubSubHubbub was created by Google engineers (Google run FeedBurner too) but it’s really a brilliant protocol, in my opinion, compared to something using Jabber/XMPP or worse which is overly complex (with a few exceptions) for this use case (HTTP+REST FTW!). I can see this easily taking off in a big way in the future once a number of full stream uses exist – maybe Google Reader will come next and that’s hugely popular.

Related posts:

  1. Zend_Feed_Reader: Approved for Combat!
  2. Zend_Feed_Reader promoted to Zend Framework trunk (watch out for ZF 1.9!)
  3. OAuth Specification and Zend Framework/PEAR Proposal
  4. Released into the wild: Zend Framework 1.0.0
  5. Zend_Yaml Proposal added