On 07. aug. 2012 18:10, Patrick Ohly wrote:
On Tue, 2012-08-07 at 17:41 +0200, Ove Kåven wrote:
> On 07. aug. 2012 10:15, Patrick Ohly wrote:
>>> it be safer to generate the anchor in beginSync, so if the user does
>>> anything during the sync, the next sync can catch it?
>> Then changes made by SyncEvolution after beginSync() would be reported
>> in the next sync as changes which need to be transmitted to the peer,
>> which would be wrong.
> Is that really a big issue? I figured we're selecting on last
> modification times here. By causality, assuming all clocks are mostly in
> sync, typical events transmitted in a synchronization would have a
> last-modification-time *before* the sync began, and that same
> last-modification time would be replicated on the other side, and thus
> also be before the beginSync time, and therefore, not picked up by the
> next beginSync.
I'm thinking of the items which are added or modified during the sync on
behalf of the remote peer. The last-modified stamp is that of the local
storage, not the original one from the peer, and thus it is higher than
the beginSync time stamp.
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.) If
the local storage time is of interest, it should probably be kept
separate. And KCalExtended doesn't bother with keeping track of that, I
It has to be assigned by the local storage, because if it is not,
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? If it cares, all the app needs to know is that the
last-modification-time changed, it shouldn't need to be later than when
the app last checked it. I don't think a non-syncing app should be able
to assume too much about these things. Of course, this might make it
inconvenient for the app to get a list of local changes, but most apps
should have no need for that. When it's launched, it should simply load
the entries it needs (probably based on start time), no matter when they
were last modified, and then recheck its caches as needed (if the
calendar storage isn't sophisticated enough to notify it or something).