Rss cloud Vs PubSubHubBub – Should it matter ?
The RSS cloud and the pubsubhubbub (PuSH) way of notifying RSS feeds has gained some interest of late, thanks to wordpress supporting the former format. If you have never heard of these protocols, heres the low down. The RSS feed works by having a client ‘pull’ data from a feed. That is, clients keep nagging at the server every X minutes saying ‘Hey do you have something new for me ?’. The server responds with a no about 99% of the time. This leads to a lot of inefficiencies. Instead if the clients were to use a push model, the data is actually ‘pushed’ to a client automatically without the client asking for it. This is great since the client no longer makes unnecessary calls to the server. The diagrams below illustrate this.
Rss Cloud update:
The cloud is supposed to be an EC2 cloud. Thus the name Rss cloud You can get an overview of PuSH here .
So what are the differences between the two ?
|Uses the cloud tag in an RSS / ATOM feed||Triggered using <link rel="hub">|
|Simply sends a notification to the client to ping again||Sends the contents of the feed change to the client|
|Clients are automatically unsubscribed after a period of time||Clients can unsubscribe using an API call|
|A clients remote IP address is used for notification||A separate URL can be mentioned for notification|
What does this all mean for a regular RSS user ? It might mean zilch since the actual feed content does not change. The new model is similar to the Observer pattern, where clients behave like Observers and the server feed is the Observable. This model leads to a more efficient feed. Clients may well receive faster updates but would a client care ? There are a few questions open to both models, which might raise concerns about reliability.
- How will these models address the problem of clients behind a firewall ? A geek can open up a HTTP tunnel or whatever, but the average user would be clueless. This is a major problem for both protocols. Dave Winer acknowledges this. Here is an excerpt of what he has to say about being behind a firewall.
The subscriber must have a known address, therefore must not be behind a firewall or NAT. For client apps, they need some kind of proxy that has a known address. This limit is signficant, but certainly not insurmountable.
Technically, the problem is indeed surmountable, but when it comes to usability, this problem is a major headache.
- Will the new model actually mean faster updates to a feed ? Yes – if the cloud / server can find the client successfully.
- When using the RSS cloud, what happens to clients that use a dynamic IP address ? If they disconnect, the notification no longer works since the remote IP address is used for notifications.
- How do you handle authentication for a feed ? The PuSH model tech spec clearly states that only unauthenticated ATOM feeds can be served.
- Will both Atom and RSS be supported equally well. PuSH currently favors ATOM but RSS support is also mentioned in the tech spec. Rss cloud supposedly supports both Rss and Atom.
It would be interesting to see how robust this protocol / format is. It might lead to a better feeding mechanism if nothing changes for the client. Ideally, a client should be able to get better update rates for a feed and not have to know anything new about Rss cloud or PuSH. It shouldn’t matter to the client which format is used. Whether that is possible is to be seen.