Another potential solution (requires a bit of invention) would be to add a "Last-Retrieved" http header to the GET request. The server could choose to use the date to tune its response.

GET /collection-uri HTTP/1.1
Host: example.org
Last-Retrieved: Sun, 6 Nov 2005 12:00:00 GMT

Eric Scheid wrote:
On 7/11/05 2:49 AM, "James M Snell" <[EMAIL PROTECTED]> wrote:


http://example.org/entries?b={begin}&e={end}


In my current impl, it operates on the last-modified date of the entry
file (entries are stored in the file system).  This is equivalent to
app:modified but is not surfaced into the entry metadata. This date is
surfaced in the Last-Modified HTTP header when I GET or HEAD the
editable representation of the entry.


That should work then -- the APP-client needs to remember the date of it's
last sync and then go retrieve the entire listing feed to sync up.

This works because the listing feed is bounded by the dates, and thus the
APP-client knows when to stop paging. It wouldn't work the collection feed
though because it wouldn't know when to stop paging.

e.



Reply via email to