On 12/7/06 4:11 AM, "Joe Gregorio" <[EMAIL PROTECTED]> wrote:
>>> they don't solve the lost update problem, >> neither does Etag > > You must be unfamiliar with this: > > http://www.w3.org/1999/04/Editing/ Ah, you're right. Etags are useful for the lost update problem ... but that's a different problem to the syncing problem. Which is to say the lost update problem is a red herring to addressing the syncing problem, and I regret taking that bait :-P So, let me try again, this time thinking straight ... You said: > [app:modified] don't solve the lost update problem, Doesn't need to, that's a different problem, with general consensus agreeing that Etags are useful when GET/PUT entry resources. Lets not get the various operations mixed up: 1) discover which entries have been modified (this one, that one) 2) retrieve the modified entries (looks like this, looks like that) 3) check for edit conflicts before doing a big upload 4) upload changes without stomping someone else's edits For these operations, do this: 1) look at app:modified in the collection feed, paging until app:modified is what you expect 2) GET (doesn't have to be conditional, you're expecting changes) 3) HEAD, compare Etag with the Etag from (2) 4) PUT with If-Match Hmmm ... your proposal *would* work (meaning we'd know when to stop paging) IFF the collection feed is sorted by app:modified (even if app:modified wasn't in the feed, and even if that particular label wasn't used for the concept). You'd still need to define what [your term for app:modified] means though. e.
