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 > TrackingSyncSource?
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 changes. Hard to be sure. My own stance is usually "correctness always trumps performance". 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 - https://bugs.freedesktop.org/show_bug.cgi?id=52681 (*) 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
