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.