On 14/7/07 12:47 PM, "Brian Smith" <[EMAIL PROTECTED]> wrote:
> I have read through the Atom Syndication, Publishing Protocol, and Feed Paging > & Archiving documents. I didn't find anything that allows the client to tell > the server what entries it (the client) already has, so that the server can > send just the new and/or updated entries. I feel like I must have overlooked > something, because that seems like it would be the most frequent use case for > APP. Is there a separate effort underway to standardize that? If so, where can > I find information about it? generally, we punted on dynamic search parameters, leaving that for extensions (but we built in a framework for extensibility) specifically though: with APP, collection feeds are provided with most-recent edited entries first, so you simply request the collection feed and you'll receive the first page of most-recently edited entries. You can then compare atom:id and app:edited of those entries against what you already have. If they are all more recent that yours, request another page from the collection. Keep going back through the collection until you come across a page containing entries which you already have and which were not more recently edited. There's also an advanced technique involving etags which keeps track of when each etag was issued and if an old etag is sent with the request then everything since then is sent back in the response. Someone will chime in with the reference. You wouldn't really want to use the mechanism you suggested though, not once you've got a few thousand entries at the client (eg. sending a list of all the atom:ids with their corresponding app:edited values). The above method involves lots of round trips for the worst case (syncing the whole collection), but minimises traffic for the more common case (sync relatively recent changes). e.
