revjim.net

RSS Feeds are great and all, but there has to be a better way.

Using RSS as the method of encapsulating information is fine. However, polling them every hour, half hour, or thirty seconds is a bit ridiculous. There's got to be a way to let a particular server know that you're interested in being notified when changes to the feed have been made. Frontier has the right idea with its Publish and Subscribe methods. This coupled with the regular updates that are pushed to weblogs.com and the system works pretty well. Unfortunately, weblogs.com doesn't active this service for the general public to use (at least not that I can tell).

With a system like this in place, each RSS reader will be notified when feeds they monitor change. Additionally, they will receive updates almost instantly, as opposed to having to wait almost an entire refresh period before seeing the new items. The servers which serve the RSS feeds will receive less hits and therefore will utilize less bandwidth. It's a win-win situation, it seems.

A system like this can be established in two ways, and the two methods are interoperable with one another. In order to support weblogging engines that do not support this feature, a standalone server can be utilized. This server can be dedicated to serving one blog, or many blogs. Or, if the blogging engine itself supports this behavior directly, each server can handle its own update notifications. I will outline the flow of each type of server.

Standalone Server

In a standalone environment, the server must accept update notifications and send out update notifications. Additionally, it must accept subscription requests.

It should accept update notifications via the same interface used by weblogs.com and blo.gs. Most weblogging applications already support sending update notifications in this fashion, which makes the standalone server easy to integrate.

After receiving an update ping from the website, the standalone server would consult the list of subscribers and send an XML-RPC notification to each of them.

Additionally, by using information contained within the RSS feed itself, a RSS reader should be able to determine the XML-RPC server and method to call in order to subscribe to update notifications for a particular feed. Therefore, an RSS reader would, initially, download the RSS feed. Upon detection of this additional information, it should send a subscription request to the server specified in the RSS feed and stop polling the RSS feed on regular intervals. As a safety-net, an RSS reader might choose to still poll an RSS feed once every 2 or 3 days, just to make certain that the server handling update notifications didn't fail for some reason. Aside from that, the RSS reader would only request the RSS feed after it received notification that a particular feed has been updated.

Integrated Server

When a blogging engine supports this behavior natively, the need to send an initial update notification is removed.

When the blogging engine receives a new article from its author, it should send out an update notification to its subscribers in the same fashion as the standalone server.

An integrated server should also accept subscription requests like the standalone server does.

A Problem

In order to receive the update notification, the RSS reader must be capable of listening on an external port, which may not be possible for those RSS Readers that run behind firewalls. In this case, it might be advantageous to implement a a stored notification method.

The stored notification method can be implemented in several ways. While it wont help to reduce unneeded network traffic much if integrated servers also supported a stored notification method, implementing stored notifications as a separate standalone server would be advantageous. An RSS reader would merely inform its notifiers of an alternate location to send updates. When the server at that location receives and update it would store them until requested by the RSS Reader. Periodically (and possibly more frequently) the RSS Reader will use another method to check for stored notifications.

Support

The problem with a concept like this is, it only really works if mass amounts of people start to support it. Fortunately, most blogs update either blo.gs or weblogs.com. This means that, if a standalone server meant for mass usage were to start by polling weblogs.com and blo.gs for updated weblogs, the system could be used almost immediately regardless of whether the author of the RSS feed you intend to read supports this use or not. However, without an RSS reader supporting this operation, it doesn't do anyone any good at all.

Comments? Questions? Suggestions?