Brian Smith wrote:
> 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?
>
It would be app:edited
> [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.
>
Note that I specifically indicated the rolling window feed paging model.
Yes, there are ways of doing the paging where the pages are stable, and
if we can rely on folks doing it that way consistently then paging is
fine. The key requirement is that the snapshot has to remain stable
throughout the sync process.
That said, however, once the initial sync is completed, subsequent
incremental sync's are much more efficient if paging is not used (e.g.
give me one feed document describing just the things that have changed
over the last twelve hours, etc).
> 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.
>
Again, this would work so long as the pages remain stable; however, I
would very much like to see a comparison of how the two approaches
compare in terms of performance / efficiency.
- James
> - Brian
>
>
>
