On 08. aug. 2012 11:28, Patrick Ohly wrote: > 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?
As far as I can tell, not without loading the entire contents of the calendar into RAM using allIncidences() or something. But the current beginSync() already uses that routine anyway. Additionally, the open() method even uses load(), thus the full calendar will already be loaded into RAM at least twice, in addition to the memory used by insertedIncidences etc (since the allIncidences memory is not freed before calling those, but after). So it's not like it could get much worse either way. It's fortunate that the N9 has more RAM than the N900 does... > 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. Even if that was true (not convinced because of the current load-the-calendar-twice thing), I'm not sure that matters. I think most users are just going to start the sync and go do something else while it finishes. Most of the time, the backups before and after takes way more time than the sync itself, anyway. > 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 If the storage doesn't provide atomic modifications anyway (which I don't think it does), I don't see much point in spending a great deal of effort on that. The user is more likely to be working on other entries than the ones with pending modifications from elsewhere - why work on an event if he/she knows there's a newer version elsewhere just waiting for a sync? Even trying would slow the sync down a lot and still not be foolproof, so it doesn't seem worth it. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
