The fact an event has exceptions does not mean this specific invitation is an exception. If the invitation includes exceptions I'd say it's definitely not an exception.
MeetingRequest has a different structure than Event. E.g. it has Recurrences property, but the later has recurrence. Look at 4th argument of recurrence_from_kolab(), but it's not that simple, I'm afraid.
The property might be unset, then itt defaults to MESSAGE_TYPE_NORMAL.
I don't think we should for performance reasons.
Right, I confused it with how we store exceptions separately in storage, but that is more a recurrenceId thing and doesn't apply to invitations (I think?).
I'm just not going to implement recurrences until we see a need to, so I'll comment/remove this entire section.
That's the idea (per spec 0 is the default).
I think get_invitation_event_from_message() is smart enough to not have a performance penalty when there's no invitation. My point is that it has a more sophisticated way to determine the invitation part. So, we'd have parity between syncroton and webclient in this regard.
My point was that the else could be removed. I also wonder what we should do when method=CANCEL (or REPLY).