Note that the pace text doesn't mention sync'ing.  This pace is not
designed to provide a solution to the complete sync problem.  It is,
however designed to provide some useful metadata in the entries
(app:modified and app:revision are good for more than just sync'ing)

Thomas Broyer wrote:
> 
> -1
> comments below
> 
> 2006/7/11, James M Snell:
>> Having a way of indicating the date the entry was last modified is a
>> good optimization to avoid having to HEAD each individual member URI to
>> get the Last-Modified header.
> 
> app:modified cannot be mandatory when used in an entry from within a
> feed. It's a good optimization to know *which* entries to
> "conditionnaly GET", only as mean of knowing where to stop
> "conditionnaly GETting" entries when "paging" the feed (i.e. as soon
> as you find an entry with an app:modified grater than or equal to –to
> account for the "modified twice a second" use case; and even when the
> date-time precision is beyond the second, the entry could still have
> been changed twice a millisecond…– the last time you sync'ed with the
> server.
> 

This pace does not make app:modified mandatory.  Nor do I make any
assumptions that app:modified is authoritative.  TAG finding 10 is very
clear on that point.

> This does not prevent using ETags in conditional GETs to update your
> local cache and in PUTs to avoid lost updates.
> 
>> Having a way of associating a unique revision token with an entry is
>> also useful.
> 
> Don't see the need…
> 

I said "useful" not "required". :-)

>[snip] 
>> == Impacts ==
>>
>> Very little.  Use of the elements are optional.
> 
> If entries are ordered by atom:updated, you'll still have to GET the
> whole feed to find each "modified but not updated" entry. Clients
> might find it better to finally GET the feed only to detect new
> entries and otherwise conditionally GET each known entry to retrieve
> the latest "revision".
> 

Yep. Again, I'm not interested in solving the sync problem in the app
spec.  At this point, all I want is to provide some useful metadata and
get out of the way.

- James

Reply via email to