On Do, 2011-09-08 at 11:23 +0200, Patrick Ohly wrote: > Exchange/OWA itself does something different: when processing two > meeting invitations for different detached recurrences, it creates two > different items (without <Exception> and thus without the original > RECURRENCE-ID). They both share the *same* UID.
And now it becomes unfair: when sending a meeting update for one of the detached recurrences, Exchange/OWA properly updated its older copy of the recurrences. This implies that Exchange must have stored the original RECURRENCE-ID internally, because otherwise it wouldn't have been able to correlate the update email with the right event. This also works when updating the other recurrence, so it is not just simply pure luck that Exchange updates the right recurrence (like, "always the latest one"). The unfair part is that the same can't be done via ActiveSync because the protocol doesn't expose the RECURRENCE-ID in this case. Thanks Microsoft, thanks a lot. This throws a wrench into my plan of creating individual items, one for each detached recurrence, because it simply wouldn't result in the same data as created by Exchange itself. For example, importing meeting updates for these events wouldn't work. My plan B is to synthesize a parent when none is available. It'll have to have the right RRULE and DTSTART, so that there is a match for each RECURRENCE-ID of each detached recurrence. EXDATEs could be used to avoid having the synthesized parent show up in the calendar on recurrences where there is no detached recurrence. Highly complicated... Perhaps something simpler will also work: add one dummy RRULE which doesn't match any RECURRENCE-ID. That matches the result of "recurring meeting created, detached recurrences created, recurring meeting modified with different recurrence rule". A real use case, let's hope Exchange supports it. -- 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
