Re: [SyncEvolution] Nokia N9 sync with task and notes support
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.