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 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. 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
