On Wed, 2012-08-08 at 10:54 +0200, Ove Kåven wrote:
On 08. aug. 2012 10:48, Patrick Ohly wrote:
> On Wed, 2012-08-08 at 10:17 +0200, Ove Kåven wrote:
>> What made you choose to use time-based change tracking in KCalExtended
>> if you don't like it?
> The backend started as a skunk work project to work with and verify the
> calendar API in MeeGo at a time when SyncEvolution wasn't the official
> sync solution for MeeGo. Because the native sync solution was using
> time-based change tracking, it made sense to test that.
> I never got around to changing it later. It wasn't relevant until you
> picked it up for the N9 port of SyncEvolution.
Right. Do you think it's best if I look at converting it to
Can KCalExtended efficiently report UID, RECURRENCE-ID and
LAST-MODIFIED? In that case, moving to a TrackingSyncSource based
approach with UID+RECURRENCE-ID as key and LAST-MODIFIED as revision
string is the better solution because it handles (some) concurrent
modifications by the user. If not, then sticking with the time-based
change tracking might be better. Its performance advantage is probably
large enough that users prefer that over better handling of concurrent
Hard to be sure. My own stance is usually "correctness always trumps
When you switch to TrackingSyncSource because it handles concurrent
changes, then perhaps you might also want to start detecting conflicts
during the sync (item was not modified when sync started, user modifies
item, sync needs to store an updated of that item that it received
during the sync) - this is something that I never got around to
implement with EDS or WebDAV (*). The right reaction would be to reject
the update and let the engine deal with the conflict in another sync
session (or iteration, something that SyncEvolution 1.2.99.x can do when
talking to itself). Totally untested, though -
(*) EDS doesn't have a good API for it, one would have to emulate it
with checking the current state again shortly before writing. WebDAV
could do it via ETag checks in the PUT header. Unfortunately Google
Calendar has so many bugs (and workarounds for them) that this atomic
update would not work for it. Might work with other servers.
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.