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
Can KCalExtended efficiently report UID, RECURRENCE-ID and
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
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 -
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.