We have gone over what you make example of here
many times now.
The rub seems to be that you think that getting insignificant
updates on sync is important. I for one don't, in general.
I know you need to moderate your wiki. That is a little
beyond basic editing, though.
If you have a special case where you need to moderate
all updates (your example from another message) you
can always implement a separate feed showing only
entries that are marked with a "needs moderation"
extension. You moderate them, remove your flag, and
they disappear from your moderation queue.
Workflows can deal with a lot of border cases.
- Luke
On 11/6/05, Eric Scheid <[EMAIL PROTECTED]> wrote:
>
> 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.
>
>
>
