Using Change Logs Effectively
The change log resources (described in Change Logs) expose all the content items in a protection domain, ordered by their last date of modification.
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 Engine 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 Engine'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.