On Sun, 2015-07-19 at 23:10 +0100, Graham Cobb wrote:
On 16/07/15 23:06, Graham Cobb wrote:
> On 13/07/15 11:53, Patrick Ohly wrote:
>> I also wonder whether the server can be told to avoid incremental
>> updates in the first place.
>
> I will look into whether I can find out under what circumstances the
> Change is being sent and whether I can avoid it. It only occurs with
> very a small number of events (currently 2 out of over 2000 in my
> calendar) but I am not sure if it is to do with the event or the type of
> change, etc.
It seems that there is no way to ask for the full event to be provided
by the server. It always sends the <Change> message (unless you are
doing a slow sync and reading everything). In most cases, that is not a
problem: the documentation says that the object will be provided pretty
much in full (fields not specified in the <Change> should be deleted),
EXCEPT for a short list of special cases (for example, for emails,
sending a change to the "Read" flag does not mean everything else should
be deleted). Although the <Attendee> is NOT listed in the documentation
as one of those special cases, it seems it really is: if the only change
to the event is the attendee list, the whole event is NOT resent -- the
client is supposed to just note the update to the attendee and not
change anything else!
Thanks for digging into this. You are aware that you are turning into
the activesyncd maintainer? ;-}
So, my current thought is to add (yet another) hack: if a calendar
event
<Change> is received that does not include a <StartTime> then the whole
update is ignored. This means that (in this case) the attendee change
is ignored, but that is better than corrupting the whole event and
losing all the information about it.
I agree, this looks like the least evil option.
Sorry for the late response; I was on vacation.
--
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.