[announcement] PubSubHubbub 0.4

[Roman]

We are proud to announce the release of the PubSubHubbub specification version 0.4: http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.4.html.

PubSubHubbub 0.4 brings many updates and enhancements, such as:

• Content providers can use Link HTTP headers with rel="hub" when serving PubSubHubbub enabled content. This change makes PubSubHubbub suitable for distributing non-XML content, such as images or JSON.
• Hubs can notify subscribers when their subscriptions get disabled (for example, when a blog gets deleted).
• Breaking change: “sync” mode of subscription verification has been removed.
  
• Breaking change: Permanent subscriptions and Hub-initiated subscription renewals have been removed.
• Breaking change: hub.verify_token has been removed.
• The specification no longer dictates a specific protocol between the Publisher and the Hub.

There are several incompatibilities between 0.3 and 0.4. When implementing a PubSubHubbub subscriber, follow the robustness principle for best results: Be conservative in what you do, be liberal in what you accept from others.

• Don’t use “sync” mode of subscription verification because 0.4 compliant Hubs are not required to support it.
  
• Don’t rely on the Hub-initiated subscription renewals (a.k.a. permanent subscriptions) as they have been removed from the 0.4 spec.
  
• Similarly, don't use hub.verify_token. Instead, use different callback URLs when subscribing to different feeds.
• Don’t reject distribution requests without the Link HTTP headers because not all Hubs have been upgraded to the 0.4 spec.
  

When implementing a publisher:

• Embed <link rel=”hub”> and <link rel=”self”> in Atom and RSS feeds. All Hubs understand them.
  
• Use Link HTTP headers with rel=”hub” and rel=”self” when serving PubSubHubbub enabled content.
  
• Notify your designated Hub about changes to all PubSubHubbub enabled resources. Check your Hub’s documentation for details.
  

Special thanks go to the chief editor Julien Genestoux who's been leading the development of the version 0.4.

Happy subscribing and publishing!

Roman Perepelitsa,

On behalf of the PubSubHubbub team at Google.

[Jay Rossiter]

> The specification no longer dictates a specific protocol between the Publisher and the Hub.

Most ridiculous non-forward-moving change, which was objected to repeatedly, and no one ever came up with a valid reason to omit.  Because the "we'll leave it up to every hub to design their own method with absolutely no standardization" is best for the community.

Alternate methods of publication were never outlawed by the existing spec, and removing the one standardized method is absolutely ludicrous.  It means that people have to re-develop if they ever change hubs.

--
 
---
You received this message because you are subscribed to the Google Groups "Pubsubhubbub" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pubsubhubbub...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Jay Rossiter | Software Engineer/System Administrator

jros...@dlvr.it | Cell: 503.896.6187
Website: dlvr.it | RSS: feeds.dlvr.it/dlvrit

[Julien Genestoux]

Thanks for the constructive comments.
Since I don't think there is any value in repeating the same debate again, I'll let anyone read the history of that debate to figure that the hub and publishers are coupled anyway and can just decide on whatever mechanism they want.

[Jay Rossiter]

Hub and publisher are NOT tightly coupled unless they're tied into a proprietary update mechanism, which is the reason that standardization is imperative.  Using standardized methods, changing hubs is as effortless as changing a configuration variable with the hub endpoints.

The refusal to discuss this logically (then or now), is telling more of your own personal desire than it is the good of the community.