Bug 86463

Created attachment 109731 [details] [review]
implement startDate property to limit the initial calendar sync date.

I have implemented a very simple way to configure the start date, that can be configure on the calendar source and is used by caldav source implementation.


Some points that still improvements:

1- Find a better name for the property name "startDate" is too generic;
2- The current configuration key "stateDate" appears for all kind of sources would be nice to make it available only for calendar sources (is that possible).

Check attachments with my patch.

Created attachment 109732 [details]
remove unrelated changes

Comment on attachment 109732 [details]
remove unrelated changes

Is the expectation that StartDate gets updated regularly by the user? When set only once, the calendar will start to grow over time again, it will just start smaller.

I'm not sure how significant that will be and in which cases - a slow sync perhaps.

The alternative would be to have a relative time and sync events falling into the last n days, for example. When a synchronized event falls out of that time range, it should (?) be removed locally. Not sure whether additional code is needed to achieve that. The same situation occurs when the user moves the startDate forward after having synchronized.

Another corner case is events created locally outside of the time range. I suppose they shall and will be synchronized to the server. When they then get edited on the server, is the change synced back?

The patch itself looks okay at first glance. "Leve it empty" is a type (should be "Leave"). A comment that this is only implement for CalDAV would be useful.

registry.push_back() and sourcePropCalendarStartDate don't line up with the rest of the surrounding code - were tabs used for formatting?

Created attachment 109799 [details]
Use  syncInterval  property instead of startDate.

Renato, can you investigate what happens in the corner cases that I mentioned?

Beware that the patches as they were proposed caused bug #89853.

Created attachment 114818 [details]
Path with the syncIterval property

Fixed a problem in the patch for sync interval starting on January.

Created attachment 114893 [details]
full log of invalid sync

Created attachment 114894 [details]
target full log

After this patch changing the syncInterval causes sync to update events that does not changed.

Created attachment 114895 [details] [review]
Path with the syncIterval property

As you can see on target log:

                             on Client   on Server
Added:                               0           2
Deleted:                             0           0
Updated:                             0           0
Rejected with error:                 0           0
Content Data Bytes sent:          1663
Content Data Bytes received:         0
Duration of sync [seconds]:          1

It says that 2 events was added on the server.

Renato sent me additional logs privately where after a slow sync with time filter set, a two-way sync removed events on the server. What happens is:
* slow sync Google: CalDAV filter returns a VCALENDAR item containing multiple VEVENTS, some of them inside, some outside the time range
* slow sync EDS: all of these events get stored in EDS
* slow sync EDS: change tracking records all events
* two-way sync EDS: EDS time range query only lists VEVENTs inside the range.
* two-way sync EDS: change tracking detects the missing events, treats them as "deleted" and...
* two-way sync Google: ... these out-dated events get deleted.

The right fix is to post-process the CaldDAV response and only consider VEVENTs which fall into the requested time range. This needs to be done inside the backend because the CalDAV server only filters per VCALENDAR, not per VEVENT,
and also does not simplify the content of a matching VCALENDAR.

Patch needs further work, see comment #14.

The investigation and/or documentation of corner case handling (= events falling out of the time range) is also still missing.

Comment on attachment 114893 [details]
full log of invalid sync

See comment #14.

Comment on attachment 114894 [details]
target full log

See comment #14.

Comment on attachment 114895 [details] [review]
Path with the syncIterval property

Does not include post-processing of the CalDAV server response, leading to the issue described in comment #14.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/SyncEvolution/syncevolution/issues/41.