On Sun, 2011-11-06 at 18:27 +0100, Ove Kåven wrote:
> Den 05. nov. 2011 21:21, skrev Patrick Ohly:
> > On Sat, 2011-11-05 at 14:24 +0100, Ove Kåven wrote:
> >> Den 05. nov. 2011 13:27, skrev Ove Kåven:
> >>>> You can comment out the whole <parameter></parameter> part or remove it
> >>>> to try out whether it works.
> >>>
> >>> I'll give it a shot, thanks...
> >>
> >> Well, that works for the entries where SyncEvolution is adding EXDATEs
> >> itself, but for those EXDATEs which have already been pushed to Google
> >> and is coming back from Google with TZIDs, there's still a problem... I
> >> suppose it'll take a rule for the non-auto-generated EXDATEs too.
> >
> > Attached two patches, both also committed to the maemo5-recurrences
> > branch.
> >
> > The first one should suppress the TZID also for regular EXDATEs.
> >
> > The second one attempts to add that time zone information back when
> > reading from the storage.
> >
> > Both patches are completely untested.
>
> diff --git a/src/syncevo/configs/scripting/11calendar.xml
> b/src/syncevo/configs/scripting/11calendar.xml
> index fe38eb6..c47958f 100644
> --- a/src/syncevo/configs/scripting/11calendar.xml
> +++ b/src/syncevo/configs/scripting/11calendar.xml
> @@ -193,8 +193,10 @@
> // the Maemo calendar storages because it uses EXDATE
> // without TZID.
> if (!ISFLOATING(DTSTART)) {
> - STRING tz = TIMEZONE(DTSTART);
> + STRING tz;
> + tz = TIMEZONE(DTSTART);
> if (tz != "UTC") {
> + INTEGER i;
> i = 0;
> while (i<SIZE(EXDATES)) {
> if (ISFLOATING(EXDATES[i])) {
>
> Anyway, it seems to work, now there are no more visible duplicates in
> the calendar.
Hey, progress :-)
I won't backport that to a 1.2 branch because at least in theory it
could have unexpected side effects, but I will make sure that it gets
into the master for 1.3.
There's one more issue: if you do a slow sync for the calendar with
CalDAV, the current code assumes that UID+RECURRENCE-ID can be used to
find matches reliably. That is not true if the local storage doesn't
really store them, as for the Maemo 5 Calendar. My expectation is that
all events will get duplicated during a slow sync.
This behavior is enabled in SyncContext.cpp with the following code:
// Choosing between comparing UID/RECURRENCE-ID vs. other
// iCalendar 2.0 properties is a hack: in local sync mode, the
// iCalendar 2.0 semantic is always picked.
if (m_serverMode && m_localSync) {
SharedKey sessionKey = m_engine.OpenSessionKey(session);
SharedKey contextKey = m_engine.OpenKeyByPath(sessionKey,
"/sessionvars");
m_engine.SetInt32Value(contextKey,
"VCALENDAR_COMPARE_UID",
true);
}
When compiling for Maemo 5, you can disable that whole section. The
proper solution for SyncEvolution 1.3 will be to let backends declare
whether they support UID/RECURRENCE-ID.
--
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
