Polling the Previous Link

As with most Atom feeds, the usual way to use them is to poll the original feed URI (for example http://host-ip-address/webservice/escenic/changelog/section/nnn) at regular intervals, in order to see what’s changed. If the number of changes exceeds the page size, the client can follow the next links until it reaches the page containing the last entry it processed.

Although this approach is a common way to use Atom feeds, it is less than optimal if the polling frequency is high, or if many clients are involved, as may be the case with the Content Store web service. The first page of the change log, an Atom feed of several kilobytes, must be re-rendered every time the original feed URI is polled. Since most of the Content Store's caches are not used due to authentication, the server is required to serve the same page very frequently, which has a detrimental effect on performance, and does not scale well with multiple clients or higher polling frequencies.

For this reason, the change log feeds include links that go right to the "edge" of the list, allowing clients to poll the actual start of the list instead of just the first page. This "edge" manifests itself as a previous link on the first page. It may initially seem illogical to have a previous link, implying as it does that there is a page before the first page. It is, however, very useful: there is a page before the first page, but it is empty unless a new change has been added to the log since the last poll. Once a client has polled the original feed once, it can subsequently poll the previous link. If no changes have been added, then the web service will return an empty feed, consuming very few server resources.

When new content items are added to the change log (or existing content items are modified and therefore moved to the top of the change log), polling the previous link will no longer return an empty feed: it will contain entries for all the new changes. The client can deal with these changes, and then continue polling this feed's previous link.

The consequence of using this approach is that most clients will be polling an empty feed most of the time, and therefore consuming a relatively small amount of server resources: the server is only required to actually render content items when there are changes to communicate to the clients. It also makes client application code simpler, since the client does not need to remember the last entry it processed, and compare it with each entry to determine whether it is new: all entries in the feed returned by the previous link are guaranteed to be new, and do not need to be checked.