On Wed, 2012-08-08 at 10:48 +0200, Ove Kåven wrote:
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*.
I wasn't there when iCalendar 2.0 was defined, so I can only speculate
about the reasons for doing it. To me, it kind of makes sense, but I
also agree that more explicit tracking of when a user changes something
could be useful.
But yes, maybe the spec is more insane than I thought. I suppose I
shouldn't be surprised by much these days.
There are a lot of things in PIM which can be surprising ;-)
> 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.
Unfortunately there are a lot more common problems with sync
implementations which have that effect. Don't get me started.
> Assume there is an item X with LAST-MODIFIED time x1 = 150 and
> 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 =
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.
Agreed. However, it is a simplification that may be hard to enforce.
It's mute anyway, because as you found, KCalExtended enforces the
updating of LAST-MODIFIED, and thus even a single sync app cannot store
a foreign LAST-MODIFIED even if it wanted to.
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.