On 08. aug. 2012 09:10, Patrick Ohly wrote: >> 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?
Never mind, I found the place it updates the last-modified-time. It was hiding in a different source file than the code to update the created-time. (I assumed they would be near each other in the code, but apparently not...) > 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. What made you choose to use time-based change tracking in KCalExtended if you don't like it? _______________________________________________ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
