An example of borken syncing.
The discussion to date assumes that it is sufficient to only compare against
atom:updated, and that app:modified is not surfaced inside the feed. My
position is that syncing should include all changes, not just those marked
as significant by the publisher.
For the sake of brevity in these examples, i'm only using a simple serial
for atom:id, and just times for atom:updated and app:modified.
Example 1:
The collection feed is sorted by reverse atom:updated, the last time I
synced was at 0:15:00, I'm looking for all changed entries (including
insignificant), and my server returns the collection feed with a page size
of two entries.
atom:id atom:updated app:modified
8 0:57:57 0:57:57
10 0:57:57 0:57:57
6 0:47:18 0:47:18
4 0:35:00 0:35:00
7 0:30:35 0:30:35
9 0:20:05 0:50:05
1 0:14:57 0:14:57
2 0:11:28 0:11:28
3 0:01:16 0:52:02 <--
5 0:00:06 0:00:06
So, if the APP-client were to compare only atom:updated, and the feed is
paginated by atom:updated, then once it got to page 4 it might reasonably
assume it doesn't need to go back any further (because it has now retrieved
a page in which all entries have atom:updated older than when it last
synced). It would thus fail to find entry #3 in page 5. Even if it were to
go one further page, the APP-client would not see that entry #3 has changed.
Example 2:
The collection feed is sorted by reverse app:modified, the last time I
synced was at 0:15:00, I'm looking for all changed entries (including
insignificant), and my server returns the collection feed with a page size
of two entries.
atom:id atom:updated app:modified
8 0:57:57 0:57:57
10 0:57:57 0:57:57
3 0:01:16 0:52:02
9 0:20:05 0:50:05
6 0:47:18 0:47:18
4 0:35:00 0:35:00
7 0:30:35 0:30:35
1 0:14:57 0:14:57
2 0:11:28 0:11:28
5 0:00:06 0:00:06
So, if the APP-client were to compare only atom:updated, and the feed is
paginated by app:modified, then once it got to page 2 it might reasonably
assume that it doesn't need to go any further back (because it now has a
page with a member whose atom:updated is older than when it last synced,
which implies that the next and further pages would only have members even
older than that member). It would thus fail to find entry #6, #4, and #7;
all of which are not insignificant.
Both of these examples have the APP-client assuming it can stop paging back
through the collection by comparing atom:updated. The alternative is to page
back through the entire collection, which is undesireable.
So what to do? Firstly, sorting only by atom:updated just won't work since
very old entries which are modified will remain hidden behind many pages.
So, sort by app:modified, but that means we need to put app:modified into
the feed. Yes, app:modified can be surfaced in the Date-Modified HTTP header
for the entry, but we'd have to first know that we need to at least HEAD the
entry before we get to see that Date-Modified header, and we can't know that
from the collection feed.
Alternatively, we might use a {since-date} driven listing or RFCxxxx+FEED
approach. If this is not legislated in the core we create interoperability
problems ... my APP-client can't sync with your APP-server.
