Funambol, Memotoo, ...: workaround for detached recurrences
@pohly
Submitted by Patrick Ohly Assigned to SyncEvolution Community
Description
---- Reported by patrick.ohly@intel.com 2010-04-22 01:19:10 +0000 ----
Problem: recurring events are shown twice by web services when modifying specific instances of it.
Problem was originally discussed in the "[SyncEvolution] UID/RECURRENCE-ID / detached recurrence / Funambol / Memotoo (was: Re: A synchronization server named Memotoo)" mail thread.
Root cause: many servers ignore UID and RECURRENCE-ID and thus display recurring events and detached recurrences incorrectly after sent by SyncEvolution.
In iCalendar 2.0, detached recurrences are linked to the recurring event
via their UID. If there is a VEVENT with UID=<foo>
and
RECURRENCE-ID=<date>
, then the main event is not to be displayed on
<date>
, only the detached recurrence is.
In addition, some software also adds an EXDATE exception in the main
event for <date>
. I don't think this is required.
- a detached recurrence on Evolution is duplicated on Memotoo but not on Evolution, even after resync.
This I can reproduce, and it fits my theory. When modifying one recurrence, Evolution 2.38.3 did not update the recurring event, so all that Memotoo is sent is one VEVENT with UID and RECURRENCE-ID. It then ignores the UID and thus displays the main event and the detached recurrence.
Thomas, does that make sense? Any suggestions how this could be fixed?
We've had the same problem with Funambol. At that time I didn't have an idea, but after writing down the explanation above and thinking some more about it, here's something that might work: when a new VEVENT gets added in Evolution with RECURRENCE-ID for an existing, unmodified recurring event, then modify the recurring event by adding an exception. Then sync both the main event and the child to the server.
Evolution doesn't do this because iCalendar 2.0 doesn't require it, but as workaround for servers with incomplete iCalendar 2.0 semantic (like Memotoo and Funambol) it is necessary and should have no negative side effects (well, except for more complicated client code and slightly increased network traffic).
---- Additional Comments From jingke.zhang@intel.com 2010-06-01 19:33:33 +0000 ----
The depending https://bugs.meego.com/show_bug.cgi?id=1916 has been fixed well.
---- Additional Comments From patrick.ohly@intel.com 2011-10-26 14:46:49 +0000 ----
(In reply to comment 0)
We've had the same problem with Funambol. At that time I didn't have an idea, but after writing down the explanation above and thinking some more about it, here's something that might work: when a new VEVENT gets added in Evolution with RECURRENCE-ID for an existing, unmodified recurring event, then modify the recurring event by adding an exception. Then sync both the main event and the child to the server.
The CalDAV backend does this for the Maemo Calendar backend, see "[SyncEvolution] Recurrences in Maemo 5".
The problem is that this transformation really belongs into the engine. I don't want to add such hacks also to the EDS calendar backend. The only sane way to solve this issue is improving the Synthesis engine so that it works with a set of items internally, see https://bugs.meego.com/show_bug.cgi?id=23761.
--- Bug imported by patrick.ohly@gmx.de 2012-07-29 20:36 UTC ---
This bug was previously known as bug 1180 at https://bugs.meego.com/show_bug.cgi?id=1180 This bug depended on bug(s) 23761 1916.