On Wed, 2012-08-08 at 06:57 +0200, Ove Kåven wrote: > Den 08. aug. 2012 02:42, skrev Ove Kåven: > > As far as I can tell from the sources, at least KCalExtended's Tracker > > storage stores and selects on the stamp of the time stored in the > > received entry, not the local time of reception. > > > > 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. (I did see one instance of possible brokenness > > in KCalExtended's SQLite backend regarding the created-time, but not in > > the Tracker backend, which is probably what's actually used here.) > > Checked again, and it seems that's not the case. It's using the SQLite > backend, not the Tracker backend, Still, even there, the > last-modified-time remains untouched from what the peer provides, only > the created-time seems to get overwritten.
Then it would be the responsibility of the app to update the LAST-MODIFIED - see my other mail about the semantic of that field. I kind of hoped that the storage does it automatically to avoid the need for remembering that semantic aspect when writing apps, but I see how it might be useful to let the app decide whether data really changed. On the other hand, if nothing changed, why does the app write the item into storage? > I suppose syncevolution does not care about the difference between > inserts and updates. If modifiedIncidences also sees inserts, it might > be fine to just not use insertedIncidences (which checks created-time), > and rely solely on modifiedIncidences, to get the behaviour we want. I > guess I'll do some checking. > > Anyway, yes, even if this works, this kind of change tracking is not > ideal since it's only reliable if we only sync with *one* peer, not > many. But these are consumer devices, it's probably fine to assume that, > that's what users are used to. Otherwise, perhaps the backend should > have a config option to give it a more TrackingSyncSource-like > behaviour, slower and requires more storage, but works with multiple > sync peers? That might be an option. But I suspect that users would forget to set that flag when configuring multiple peers because they don't know about it. Perhaps the GUI can ensure that it is set correctly... which might become a problem when it is not set initially and later gets set when adding that second peer. -- 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
