James Snell wrote at http://www.snellspace.com/wp/?p=818:
> <x:link-template rel="sync" > pattern="http://.../myfeed;sync?{join|&|since,until}" /> <snip> > If the until param is omitted, it is assumed to be “now” > as determined by the server. The server must indicate the > until date in the response feed. If the since param is > omitted, it is assumed to be a timestamp indicating the > moment the collection was created. Do "since" and "until" refer to atom:updated or app:edited? > The URL returns a single, complete Atom feed listing ONLY > the entries that have been modified within the window of > time specified. It is unreasonable to require this to be done in a single page if there are many entries that need to be sent during the sync. Consider a collection that has thousands of items and a client that always uses http://.../myfeed;sync?since=1900-01-01T00:00:00Z to constantly download the entire collection. Paging is still needed. <snip> > We can differentiate new and updated entries using the > x:sync element and the existing atom:published, > atom:updated and app:edited timestamps. Most AtomPub applications will consider an entry to be updated if they already had a copy of the entry with an earlier app:edited, and new otherwise, without needing FeedSync at all. FeedSync is more useful for non-AtomPub feeds because many implementations do not do a good job of managing the atom:updated property of entries. <snip> > And Because the entire snapshot is contained within a single > feed document, we do not have to worry about the race > condition that is inherent in the rolling window feed > paging model. The race condition is not an inherent problem in the paging model; it is an implementation issue. In my implementation, I do all the paging in my collection feed using links like: <link rel='prev' href='?until={END}'/> <link rel='next' href='?since={START}'/> Where START is the earliest app:edited in the current page and END is the latest app:edited in the current page. By assuring that all entries with the same app:edited value are collected on the same page, and following the specification requirements about the ordering of the feed, there is no chance for a race condition. Furthermore, the first page of the feed (the collection subscription document) contains: <link rel='next' href='?since={START}'/> Where START is the latest app:edited value in the collection. As a result, any client can efficiently sync with the collection like so: 1. When initially subscribing to the collection, pull down the subscription document. Remember the value of the 'next' as SYNC and page backwards using the 'prev' link relation. 2. Whenever the client needs to re-sync with the collection, instead of retrieving the subscription feed document as usually, pull the feed document from the SYNC IRI. Then page forward using the 'next' link relation, stopping at the page that has <link rel='next' href=''/> (which will be a feed document with no entries). Remember the IRI of that last page as SYNC, for subsequent re-syncs. - Brian
