Re: [SyncEvolution] UID/RECURRENCE-ID / detached recurrence / Funambol / Memotoo

On Thu, 2010-04-15 at 11:06 +0200, Patrick Ohly wrote: > On Wed, 2010-04-14 at 20:29 +0100, Ahmed Guellil wrote: > 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. > > My theory is that this fails because Memotoo does not support the UID > property (known limitation) *and* the software which created the > recurring event did not include an exception. > > Let's test... hmm, I don't find a way to modify one particular > occurrence on the Memotoo web interface, so I cannot test the > Memotoo->Evolution case. > > Ahmed, I need you help there. Can you save both the main event and the > detached recurrence in Evolution and attach it to your reply? Please > remove sensitive information. > This is still relevant. What I don't understand is how Memotoo avoids displaying the recurring event on the day of the detached recurrence. If it is via EXDATE, then it should also work in Evolution. Unless Memotoo never sends the exception... perhaps you can modify the recurring event, sync with Evolution using a higher log level ("syncevolution --run --sync-property loglevel=4 memotoo"), then check the log ("syncevolution --print-sessions memotoo") and quote the incoming VEVENT as it is sent by Memotoo? >> - 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).