11:07 a.m.
I've been looking into why, when I sync my trusty old N900 with Google
Calendar via CalDAV, the calendar shows "duplicate" events when I've
changed an instance of a recurrence in Google Calendar. (One event will
show with the old data, and one with the new data.)
Perhaps the answer would have been obvious if I knew the ical standard
better. It seems that when Google records a changed instance, they add
an event with the same global UID as the original one, and then uses
RECURRENCE-ID to identify the particular instance.
Since the Maemo 5 (Fremantle)'s calendar-backend does not store the
global UID, that was bound to fail. (And, as far as I call tell,
calendar-backend also only stores the RECURRENCE-ID if a RRULE is also
present in the same event, which it isn't - and even when it stores the
ID, it doesn't use it.)
It looks like this calendar-backend will only honor RDATEs and EXDATEs,
which must be stored in the original event (the one with the RRULE).
Then, I suppose, the changed instances would look like single events to it.
Is there any reasonable way SyncEvolution could do that conversion, so I
won't have to keep scratching my head trying to remember which was the
original, superseded event?
11:17 a.m.
On Sun, 2011-09-18 at 13:07 +0200, Ove Kåven wrote:
[add EXDATE to parent event for detached recurrences]
Is there any reasonable way SyncEvolution could do that conversion,
so I
won't have to keep scratching my head trying to remember which was the
original, superseded event?
Let's see...
In the CalDAV backend, all related VEVENTs sharing the same UID are
available together. Adding a detached recurrence will automatically mark
the parent event as updated, so it will be stored anew in the local
storage. It wouldn't be too hard to add some code which copies all
RECURRENCE-IDs into EXDATEs.
However, conceptually this is a hack. This conversion belongs into the
translation layer between CalDAV (one item per UID) and the
engine/Maemo5 calendar (one item per VEVENT), if and only if that other
backend doesn't support UID. But at that level semantic conversions
aren't easy anymore, because that level doesn't know anything about
iCalendar.
Here's a possible solution which is perhaps not too hideous:
1. introduce a new RECURRENCE-IDS field: an array of time stamps,
similar to EXDATE
2. map it to an iCalendar 2.0 X-SYNCEVOLUTION-RECURRENCE-ID
property which is only used internally
3. the CalDAV backends and ActiveSync backends create such
properties in the parent VEVENT
4. the Synthesis engine passes it through to the Maemo 5 backend
(thanks to points 1 and 2)
5. the Maemo 5 backend treats it like EXDATE when storing
Retrieving an updated parent event from the Maemo 5 backend then will
add normal EXDATEs to the CalDAV server, which is redundant, but not
wrong.
How does that sound?
--
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.
1:13 p.m.
Den 29. sep. 2011 13:17, skrev Patrick Ohly:
Here's a possible solution which is perhaps not too hideous:
1. introduce a new RECURRENCE-IDS field: an array of time stamps,
similar to EXDATE
2. map it to an iCalendar 2.0 X-SYNCEVOLUTION-RECURRENCE-ID
property which is only used internally
3. the CalDAV backends and ActiveSync backends create such
properties in the parent VEVENT
4. the Synthesis engine passes it through to the Maemo 5 backend
(thanks to points 1 and 2)
5. the Maemo 5 backend treats it like EXDATE when storing
Retrieving an updated parent event from the Maemo 5 backend then will
add normal EXDATEs to the CalDAV server, which is redundant, but not
wrong.
How does that sound?
Hmm. I suppose that'd work (though I'd have to learn what APIs to use to
make the backend convert these properties). It'd perhaps be better if
the added EXDATEs could be automatically stripped later, but if you
don't think they're going to hurt...
I've gotten another problem with recurrences, though; after changing
some stuff around in Google Calendar, including rescheduling a single
instance of a recurrent weekly appointment to a different day, I get the
fatal error "new CalDAV item does not have right RECURRENCE-ID". I
suppose that might also be related to Maemo 5 not storing RECURRENCE-IDs?
I can send the logs privately...
4:41 p.m.
On Fri, 2011-09-30 at 15:13 +0200, Ove Kåven wrote:
Den 29. sep. 2011 13:17, skrev Patrick Ohly:
> Here's a possible solution which is perhaps not too hideous:
> 1. introduce a new RECURRENCE-IDS field: an array of time stamps,
> similar to EXDATE
> 2. map it to an iCalendar 2.0 X-SYNCEVOLUTION-RECURRENCE-ID
> property which is only used internally
> 3. the CalDAV backends and ActiveSync backends create such
> properties in the parent VEVENT
> 4. the Synthesis engine passes it through to the Maemo 5 backend
> (thanks to points 1 and 2)
> 5. the Maemo 5 backend treats it like EXDATE when storing
>
> Retrieving an updated parent event from the Maemo 5 backend then will
> add normal EXDATEs to the CalDAV server, which is redundant, but not
> wrong.
>
> How does that sound?
Hmm. I suppose that'd work (though I'd have to learn what APIs to use to
make the backend convert these properties).
Your backend gets an iCalendar VEVENT specifically formatted for it by
the engine. It will be possible to tell the engine that RECURRENCE-IDS
field entries are to be mapped to the regular EXDATE when formatting for
your backend.
Your backend needs to set SynthesisInfo::m_backendRule to a unique
string (MAEMO?) in a specialized version of getSynthesisInfo() and the
iCalendar 2.0 profile needs to take that into account.
It'd perhaps be better if
the added EXDATEs could be automatically stripped later, but if you
don't think they're going to hurt...
Hmm, the inverse operation could strip out redundant EXDATEs again, but
I am not sure whether it is worth the effort.
I've gotten another problem with recurrences, though; after
changing
some stuff around in Google Calendar, including rescheduling a single
instance of a recurrent weekly appointment to a different day, I get the
fatal error "new CalDAV item does not have right RECURRENCE-ID". I
suppose that might also be related to Maemo 5 not storing RECURRENCE-IDs?
Yes, that should be it.
The code is in CalDAVSource::insertSubItem() in CalDAVSource.cpp:
if (subid != knownSubID) {
SE_THROW("new CalDAV item does not have right
RECURRENCE-ID");
}
I bet subid is empty here. Instead of bailing out, the CalDAV source
could attempt to silently restore the right icalproperty. It's a bit
tricky because the knownSubID is the date-time value without the
corresponding time zone (like EDS does it). One would have to find the
dtstart of the parent event and use its time zone + TZID.
--
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.
3:06 p.m.
Hello Ove!
Just going through older emails... do you need some help with this or
are the pointers enough? I could provide a untested patch which changes
the core infrastructure as suggested, as a starting point.
Bye, Patrick
On Fri, 2011-09-30 at 18:41 +0200, Patrick Ohly wrote:
On Fri, 2011-09-30 at 15:13 +0200, Ove Kåven wrote:
> Den 29. sep. 2011 13:17, skrev Patrick Ohly:
> > Here's a possible solution which is perhaps not too hideous:
> > 1. introduce a new RECURRENCE-IDS field: an array of time stamps,
> > similar to EXDATE
> > 2. map it to an iCalendar 2.0 X-SYNCEVOLUTION-RECURRENCE-ID
> > property which is only used internally
> > 3. the CalDAV backends and ActiveSync backends create such
> > properties in the parent VEVENT
> > 4. the Synthesis engine passes it through to the Maemo 5 backend
> > (thanks to points 1 and 2)
> > 5. the Maemo 5 backend treats it like EXDATE when storing
> >
> > Retrieving an updated parent event from the Maemo 5 backend then will
> > add normal EXDATEs to the CalDAV server, which is redundant, but not
> > wrong.
> >
> > How does that sound?
>
> Hmm. I suppose that'd work (though I'd have to learn what APIs to use to
> make the backend convert these properties).
Your backend gets an iCalendar VEVENT specifically formatted for it by
the engine. It will be possible to tell the engine that RECURRENCE-IDS
field entries are to be mapped to the regular EXDATE when formatting for
your backend.
Your backend needs to set SynthesisInfo::m_backendRule to a unique
string (MAEMO?) in a specialized version of getSynthesisInfo() and the
iCalendar 2.0 profile needs to take that into account.
> It'd perhaps be better if
> the added EXDATEs could be automatically stripped later, but if you
> don't think they're going to hurt...
Hmm, the inverse operation could strip out redundant EXDATEs again, but
I am not sure whether it is worth the effort.
> I've gotten another problem with recurrences, though; after changing
> some stuff around in Google Calendar, including rescheduling a single
> instance of a recurrent weekly appointment to a different day, I get the
> fatal error "new CalDAV item does not have right RECURRENCE-ID". I
> suppose that might also be related to Maemo 5 not storing RECURRENCE-IDs?
Yes, that should be it.
The code is in CalDAVSource::insertSubItem() in CalDAVSource.cpp:
if (subid != knownSubID) {
SE_THROW("new CalDAV item does not have right
RECURRENCE-ID");
}
I bet subid is empty here. Instead of bailing out, the CalDAV source
could attempt to silently restore the right icalproperty. It's a bit
tricky because the knownSubID is the date-time value without the
corresponding time zone (like EDS does it). One would have to find the
dtstart of the parent event and use its time zone + TZID.
1:35 a.m.
Den 13. okt. 2011 17:06, skrev Patrick Ohly:
Hello Ove!
Just going through older emails... do you need some help with this or
are the pointers enough? I could provide a untested patch which changes
the core infrastructure as suggested, as a starting point.
Sure, that would help... I wasn't sure where to start, and it hasn't
been easy to find time to study how the core engine works - there's a
C++ class jungle in there.
Thanks,
Ove
7:56 a.m.
On Sat, 2011-10-15 at 03:35 +0200, Ove Kåven wrote:
Den 13. okt. 2011 17:06, skrev Patrick Ohly:
> Hello Ove!
>
> Just going through older emails... do you need some help with this or
> are the pointers enough? I could provide a untested patch which changes
> the core infrastructure as suggested, as a starting point.
Sure, that would help... I wasn't sure where to start, and it hasn't
been easy to find time to study how the core engine works - there's a
C++ class jungle in there.
True, this particular change requires some familiarity with how the
different pieces work together.
I've pushed the necessary changes to the maemo5-recurrences branch,
based on current master. It should be possible to cherry-pick this back
onto your local Maemo 5 branch:
git fetch
git cherry-pick origin/master..origin/maemo5-recurrences
I renamed the properties and field a bit compared to my original
proposal. I'm a bit unhappy about one aspect of the patch: in order to
import the additional exdates into the engine, the CalDAV backend has to
enable the additional property for import *and* and export. If this
workaround works for Maemo, then I'll change it so that the CalDAV
backend only passes the additional information to the engine without
being asked to store it (which isn't necessary).
I verified that the patch series does add EXDATEs as expected by
temporarily adding the HAVE-EXDATE-DETACHED to the Evolution calendar
backend (not committed).
--
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.
6:35 a.m.
Den 18. okt. 2011 09:56, skrev Patrick Ohly:
I've pushed the necessary changes to the maemo5-recurrences
branch,
based on current master.
Thank you very much. And I finally had a little time to look at it...
It should be possible to cherry-pick this back
onto your local Maemo 5 branch:
git fetch
git cherry-pick origin/master..origin/maemo5-recurrences
...with some conflicts that needs resolving. (I did not know how to
resolve the testcase conflict, so I didn't import that one.)
It did not seem to quite work for me. The backend now stores EXDATEs
that look like
EXDATE:19700101T000000Z
I suppose I'll need to take a look at why that happens later on.
But I guess this won't resolve the "new CalDAV item does not have right
RECURRENCE-ID" fatal error. Hmm...
Anyway, thanks so far,
Ove
12:43 p.m.
On Tue, 2011-11-01 at 07:35 +0100, Ove Kåven wrote:
Den 18. okt. 2011 09:56, skrev Patrick Ohly:
> I've pushed the necessary changes to the maemo5-recurrences branch,
> based on current master.
Thank you very much. And I finally had a little time to look at it...
> It should be possible to cherry-pick this back
> onto your local Maemo 5 branch:
> git fetch
> git cherry-pick origin/master..origin/maemo5-recurrences
...with some conflicts that needs resolving. (I did not know how to
resolve the testcase conflict, so I didn't import that one.)
It did not seem to quite work for me. The backend now stores EXDATEs
that look like
EXDATE:19700101T000000Z
I suppose I'll need to take a look at why that happens later on.
Remember to set loglevel=4 in both sync and target config, to get full
logging on both sides.
But I guess this won't resolve the "new CalDAV item does not
have right
RECURRENCE-ID" fatal error. Hmm...
Indeed, that is a different problem. I'm working on a patch.
--
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.
7:24 p.m.
Den 01. nov. 2011 13:43, skrev Patrick Ohly:
On Tue, 2011-11-01 at 07:35 +0100, Ove Kåven wrote:
> It did not seem to quite work for me. The backend now stores EXDATEs
> that look like
>
> EXDATE:19700101T000000Z
>
> I suppose I'll need to take a look at why that happens later on.
Remember to set loglevel=4 in both sync and target config, to get full
logging on both sides.
There's some bug that causes it to bork if the EXDATE has a property
(like TZID). The calendar-backend doesn't check the property anyway; it
can go to UTC if the time itself has a "Z" suffix, but no other timezone
overrides seem possible for this field.
Would you know of another of those magic rules that would remove that
TZID property?
7:37 p.m.
On Fri, 2011-11-04 at 20:24 +0100, Ove Kåven wrote:
Den 01. nov. 2011 13:43, skrev Patrick Ohly:
> On Tue, 2011-11-01 at 07:35 +0100, Ove Kåven wrote:
>> It did not seem to quite work for me. The backend now stores EXDATEs
>> that look like
>>
>> EXDATE:19700101T000000Z
>>
>> I suppose I'll need to take a look at why that happens later on.
>
> Remember to set loglevel=4 in both sync and target config, to get full
> logging on both sides.
There's some bug that causes it to bork if the EXDATE has a property
(like TZID). The calendar-backend doesn't check the property anyway; it
can go to UTC if the time itself has a "Z" suffix, but no other timezone
overrides seem possible for this field.
Would you know of another of those magic rules that would remove that
TZID property?
Sorry, I didn't follow. So you have a RECURRENCE-ID with TZID which gets
converted into an EXDATE with that TZID? And you want to have an EXDATE
instead with that TZID+value converted into UTC?
That can be done with a before-write script for the Maemo calendar
backend. Grep for VCARD_BEFOREWRITE_SCRIPT_EVOLUTION to see how such a
script is defined and enabled. The content of that script has to be a
loop over the new recurrence IDs array field.
I can provide another patch if that is what you need.
--
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.
8:24 a.m.
Den 04. nov. 2011 20:37, skrev Patrick Ohly:
On Fri, 2011-11-04 at 20:24 +0100, Ove Kåven wrote:
> Den 01. nov. 2011 13:43, skrev Patrick Ohly:
>> On Tue, 2011-11-01 at 07:35 +0100, Ove Kåven wrote:
>>> It did not seem to quite work for me. The backend now stores EXDATEs
>>> that look like
>>>
>>> EXDATE:19700101T000000Z
>>>
>>> I suppose I'll need to take a look at why that happens later on.
>>
>> Remember to set loglevel=4 in both sync and target config, to get full
>> logging on both sides.
>
> There's some bug that causes it to bork if the EXDATE has a property
> (like TZID). The calendar-backend doesn't check the property anyway; it
> can go to UTC if the time itself has a "Z" suffix, but no other timezone
> overrides seem possible for this field.
>
> Would you know of another of those magic rules that would remove that
> TZID property?
Sorry, I didn't follow. So you have a RECURRENCE-ID with TZID which gets
converted into an EXDATE with that TZID?
Well, whatever Google does. I get incoming stuff like
...
DTSTART;TZID=Europe/Berlin:20100112T141500
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=TU;UNTIL=20100518T121500Z
EXDATE;TZID=Europe/Berlin:20100329T000000
DTEND;TZID=Europe/Berlin:20100112T160000
...
Seems there are TZIDs in the RECURRENCE-IDs, yes.
And you want to have an EXDATE
instead with that TZID+value converted into UTC?
I don't need UTC, just that the TZID goes away. Without TZID, it'll use
the event's timezone (same as DTSTART, I think). Since normally, the
exceptions have the same timezone as the event itself, it's probably not
necessary to do much conversion.
That can be done with a before-write script for the Maemo calendar
backend. Grep for VCARD_BEFOREWRITE_SCRIPT_EVOLUTION to see how such a
script is defined and enabled. The content of that script has to be a
loop over the new recurrence IDs array field.
Where is that language defined?
11:57 a.m.
On Sat, 2011-11-05 at 09:24 +0100, Ove Kåven wrote:
Den 04. nov. 2011 20:37, skrev Patrick Ohly:
> On Fri, 2011-11-04 at 20:24 +0100, Ove Kåven wrote:
>> Den 01. nov. 2011 13:43, skrev Patrick Ohly:
>>> On Tue, 2011-11-01 at 07:35 +0100, Ove Kåven wrote:
> And you want to have an EXDATE
> instead with that TZID+value converted into UTC?
I don't need UTC, just that the TZID goes away. Without TZID, it'll use
the event's timezone (same as DTSTART, I think). Since normally, the
exceptions have the same timezone as the event itself, it's probably not
necessary to do much conversion.
I don't understand why an explicit TZID which specifies the event's time
zone is bad when that's the time zone that is going to be used anyway,
but so be it ;-) A bug?
Anyway, getting rid of the TZID is easy. It is generated by the TZID
parameter in the modified calendar profile:
<!-- encode as normal EXDATE when backend asks for it -->
<property name="EXDATE" show="no"
rule="HAVE-EXDATE-DETACHED" mandatory="no">
<value field="EXDATES_DETACHED"/>
===> <parameter name="TZID" default="no"
show="yes">
<value field="EXDATES_DETACHED"
conversion="TZID"/>
</parameter>
<position field="EXDATES_DETACHED" repeat="array"
increment="1" minshow="0"/>
</property>
You can comment out the whole <parameter></parameter> part or remove it
to try out whether it works.
The final solution will be to have two kinds of "include
EXDATES_DETACHED field as EXDATE" entries: one with TZID, one without.
Like this:
<!-- encode as normal EXDATE when backend asks for it -->
<property name="EXDATE" show="no"
rule="HAVE-EXDATE-DETACHED" mandatory="no">
<value field="EXDATES_DETACHED"/>
<parameter name="TZID" default="no"
show="yes">
<value field="EXDATES_DETACHED"
conversion="TZID"/>
</parameter>
<position field="EXDATES_DETACHED" repeat="array"
increment="1" minshow="0"/>
</property>
<!-- encode as EXDATE without TZID when backend asks for it -->
<property name="EXDATE" show="no"
rule="HAVE-EXDATE-DETACHED-NO-TZID" mandatory="no">
<value field="EXDATES_DETACHED"/>
<position field="EXDATES_DETACHED" repeat="array"
increment="1" minshow="0"/>
</property>
Then in the Maemo backend patch, enable HAVE-EXDATE-DETACHED-NO-TZID
instead of HAVE-EXDATE-DETACHED.
> That can be done with a before-write script for the Maemo
calendar
> backend. Grep for VCARD_BEFOREWRITE_SCRIPT_EVOLUTION to see how such a
> script is defined and enabled. The content of that script has to be a
> loop over the new recurrence IDs array field.
Where is that language defined?
Both the Synthesis configuration XML quoted above and the procedural
scripting language embedded in it are defined in the
libsynthesis/doc/SySync_config_reference.pdf
--
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.
12:27 p.m.
Den 05. nov. 2011 12:57, skrev Patrick Ohly:
On Sat, 2011-11-05 at 09:24 +0100, Ove Kåven wrote:
> Den 04. nov. 2011 20:37, skrev Patrick Ohly:
>> On Fri, 2011-11-04 at 20:24 +0100, Ove Kåven wrote:
>>> Den 01. nov. 2011 13:43, skrev Patrick Ohly:
>>>> On Tue, 2011-11-01 at 07:35 +0100, Ove Kåven wrote:
>> And you want to have an EXDATE
>> instead with that TZID+value converted into UTC?
>
> I don't need UTC, just that the TZID goes away. Without TZID, it'll use
> the event's timezone (same as DTSTART, I think). Since normally, the
> exceptions have the same timezone as the event itself, it's probably not
> necessary to do much conversion.
I don't understand why an explicit TZID which specifies the event's time
zone is bad when that's the time zone that is going to be used anyway,
but so be it ;-) A bug?
Yes, like I said, a bug. The ICalConverter code was probably not tested
with anything other than "EXDATE:", as the time string is not extracted
properly otherwise. It appears there's a fix in the git (a quite ugly
fix, but still, a fix), but that fix was apparently never merged into
the stable branches before Nokia lost interest in updating the device.
Maybe they never got around to making a cleaner fix?
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...
1:24 p.m.
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.
8:21 p.m.
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.
--
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.
8:26 p.m.
On Tue, 2011-11-01 at 13:43 +0100, Patrick Ohly wrote:
> But I guess this won't resolve the "new CalDAV item
does not have
right
> RECURRENCE-ID" fatal error. Hmm...
Indeed, that is a different problem. I'm working on a patch.
I got carried away a bit ;-) After writing tests for this particular
problem I was convinced enough that the code works that I already merged
it into the master branch.
See the attached patches.
--
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.
5:27 p.m.
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.
7:51 p.m.
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.
8:41 p.m.
Den 06. nov. 2011 20:51, skrev Patrick Ohly:
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.
You've mentioned that section before. For that reason, I've already
disabled it (about 4 months ago, apparently).
Thanks,
Ove
12:05 p.m.
On So, 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.
Thanks, merged with that fix into master.
Once it hit master and was included in testing (which it will be in the
future without having to merge first, thanks to the new automatic
integration testing), I found some drawback in that approach. Fix is in
master, you might want to back-port (without the tests):
commit ede6e65ccb7cf4180711a56c6a28c4914b25a7dd
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Mon Nov 14 12:00:37 2011 +0000
CalDAV: filter out X-SYNCEVOLUTION-EXDATE-DETACHED
If the engine got a parent event with X-SYNCEVOLUTION-EXDATE-DETACHED,
merged it internally and then wrote it back, the
X-SYNCEVOLUTION-EXDATE-DETACHED would have been stored in the CalDAV
server. Now this is avoided by removing all such properties before
storing the new or updated event.
This was previously done (and still is) as an extra precaution in the
code which adds the properties.
commit 1cd49e9ecd60b38593ef87665fe318aec7692d91
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Sat Nov 12 12:50:09 2011 +0000
CalDAV: revised RECURRENCE-ID -> EXDATE support
The previous approach (updating the internal cache) had the drawback
that X-SYNCEVOLUTION-EXDATE-DETACHED was also sent to the CalDAV
server. The work of generating it was done in all cases, even if not
needed. Found when running the full test suite.
Now the X-SYNCEVOLUTION-EXDATE-DETACHED properties are only added to
the icalcomponent that is generated for the engine in
readSubItem(). There's still the risk that such an extended VEVENT
will be stored again (read/modify/write conflict resolution), so
further changes will be needed to filter them out.
To ensure that this change doesn't break the intended semantic of
X-SYNCEVOLUTION-EXDATE-DETACHED, the presence of these properties is
now checked in the LinkedItems::testLinkedItemsParentChild test.
--
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.
3926
days inactive
3983
days old
syncevolution@synevolution.org
20 comments
2 participants
participants (2)
-
Ove Kåven -
Patrick Ohly