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.