12:49 p.m.
Hello!
Consider the following situation:
1. User A sets up a recurring meeting.
2. He invites user B for one (but not all) recurrences, which
happens to be modified (say, different summary).
3. User B receives the meeting invitation. It gets added to his
Exchange calendar.
4. User A invites him for the recurring meeting.
5. User B receives that meeting invitation.
The key question is: at step 3, is the meeting stored as a detached
recurrences, or whatever the corresponding Exchange semantic is?
If it is not, then how do Outlook/Exchange deal with the second meeting
invitation? If the existing event is not marked as a detached
recurrence, then the invitation looks like an update, which should
overwrite the old data instead of adding the parent event to it.
In SyncEvolution's client-test, this situation is covered by:
CLIENT_TEST_UNIQUE_UID=1 CLIENT_TEST_SERVER=exchange ./client-test
Client::Source::eas_event::LinkedItems_0::testLinkedItemsParentChild
Note that you need an up-to-date SyncEvolution and activesyncd source; I
changed the naming recently and fixed some aspects of the LinkedItems
testing.
What I now see is that SyncEvolution sends a VCALENDAR with one VEVENT
which has a RECURRENCE-ID. What comes back is that same event without
RECURRENCE-ID. I suspect that this will cause Evolution to fall into the
trap that I outlined above.
It depends a bit on what kind of meeting invitations are sent: is it one
for the parent, or one for parent and all detached recurrences? I don't
know, and the point is that different programs may deal with this
differently. I don't think the iCalendar 2.0 standard mandates a
particular behavior.
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Open Source Technology Center
Pützstr. 5 Phone: +49-228-2493652
53129 Bonn
Germany
11:47 a.m.
On Mo, 2011-08-29 at 13:49 +0200, Patrick Ohly wrote:
Hello!
Consider the following situation:
1. User A sets up a recurring meeting.
2. He invites user B for one (but not all) recurrences, which
happens to be modified (say, different summary).
3. User B receives the meeting invitation. It gets added to his
Exchange calendar.
4. User A invites him for the recurring meeting.
5. User B receives that meeting invitation.
I ran the experiment, with Google Calendar for creating the invitations
and Evolution and Exchange/OWA for accepting them.
The key question is: at step 3, is the meeting stored as a detached
recurrences, or whatever the corresponding Exchange semantic is?
No. Google did send an iCalendar 2.0 VEVENT with RECURRENCE-ID (as
expected), but then Exchange stored it like any other event.
If it is not, then how do Outlook/Exchange deal with the second
meeting
invitation?
They overwrite the information received earlier, which is broken. In my
test, the first invitation was for a modified recurrence (different
summary, but meeting time could also have been different). That is the
information that Google still uses after step 4, as intended. But OWA
shows the information from the recurring parent event instead.
I would love to report that Evolution did it right, but it also failed.
It imported the first invitation okay (RECURRENCE-ID stored), but then
removes the detached recurrence when importing the parent.
So what do we do? Write it off as a corner case that no-one else handles
properly either?
Right now detached recurrences without parent are simply not sent at
all. It would be fairly easy to turn a single detached recurrence into a
stand-alone event (like Exchange did in step 3), but then what is to be
done with any further detached recurrence sharing the same UID? Make
them exceptions of an event that doesn't recur? Hmm...
If the existing event is not marked as a detached
recurrence, then the invitation looks like an update, which should
overwrite the old data instead of adding the parent event to it.
And indeed, this is what happens... oh how I hate it to be right.
It depends a bit on what kind of meeting invitations are sent: is it
one
for the parent, or one for parent and all detached recurrences?
The one in step 4 only includes the parent, which IMHO makes sense,
because it avoids triggering the meeting import/acceptance process anew
for something which was already dealt with earlier.
--
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.
10:23 a.m.
On Mi, 2011-09-07 at 12:47 +0200, Patrick Ohly wrote:
Right now detached recurrences without parent are simply not sent at
all. It would be fairly easy to turn a single detached recurrence into a
stand-alone event (like Exchange did in step 3), but then what is to be
done with any further detached recurrence sharing the same UID? Make
them exceptions of an event that doesn't recur? Hmm...
I tried that. The non-recurring parent with <Exception> was accepted by
Exchange 2010, but when retrieving it again the <Exception> was gone.
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.
I'm not sure how SyncEvolution will react when it is presented two
different items with the same UID. The unspoken assumption was that UIDs
are, well, unique.
The activesyncd API also doesn't deal with this well. When asked to
store a VCALENDAR with two detached recurrences inside, it would have to
create two different items. But it can only return one ID back to the
activesyncd client.
We shouldn't change that API. Instead we need to introduce a new
semantic constraint (a VCALENDAR may only contain more than one VEVENT
if one of them is the parent) and relax another (different VCALENDAR
items may share the same UID).
That's easy to implement in activesyncd. It's harder to deal with in
SyncEvolution. <Sigh>
--
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.
10:47 a.m.
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.
3903
days inactive
3913
days old
syncevolution@synevolution.org
3 comments
1 participants
participants (1)
-
Patrick Ohly