On 08. aug. 2012 09:04, Patrick Ohly wrote: >> It makes sense that the created-time and modified-time in the entry >> should be the time the *user* modified the data, otherwise sane conflict >> resolution becomes impossible. Thus, I'd say an implementation that does >> what you say is broken. > > You seem to assume that LAST-MODIFIED is taken from the incoming data > and thus marks the time when the data was last modified somewhere. But > that's not how it works. According to the spec, the incoming > LAST-MODIFIED needs to be overwritten with the time when the modified > item actually hits the local storage. > > The spec makes sense because relying on all peers having a synchronized > time base is risky. It's hard enough to ensure locally.
Well, to me, that doesn't make sense at all. *Having* local time stamps that aren't related to user activity can be quite useful, of course, particularly for syncing. But making such stamps part of the externally visible data, without having some timestamp/revision-id reserved for user activity, does *not* make sense at all. Any revision-stamp changes visible to peers should be because of the *user*. But yes, maybe the spec is more insane than I thought. I suppose I shouldn't be surprised by much these days. > Depending on synchronized time cannot be avoided completely: > LAST-MODIFIED values from different machines still get compared when > resolving conflicts. That happens a lot less than change detection, > which must work reliably each time a sync is done. But when they do happen, they can obviously get immensely damaged by this last-modified semantic. If earlier revisions can acquire later last-modified times in a sync chain, this seems designed to make the user throw all his gadgets out the window in frustration. >>> It has to be assigned by the local storage, because if it is not, then a >>> third party app on the local side will incorrectly conclude that a >>> modified item is old and unmodified when in fact it was modified after >>> that app last looked at the database. >> >> Why would that be? > > Here's an example. > > Assume there is an item X with LAST-MODIFIED time x1 = 150 and CREATED = > 0 in the local storage. At time a1 = 200, sync app A checks for "updated > items" since time a0 = 100, the time of its last check. The app sees the > item update and remembers a1 for the next check. At time b1 = 250, app B > stores an updated version of X that it received from somewhere with x2 = > 190. Then, if app B is a regular app, it misbehaves. Only sync apps should ever save with a last-modified time earlier than the current time - and as I've noted, the timestamp scheme would also rely on there only being *one* sync app working on the same data set. If this is the case, everything should be fine. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
