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
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!
To make matter worse, the EAS protocol has no way (at least in the older
versions) to retrieve a particular event! The ONLY way to get a
particular event using the EAS protocol is to use the slow-sync approach
to download ALL events!
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.
The alternatives seem to be: never do syncs -- always download
everything so we always get the full content of every event (very
expensive, just to resolve an unusual corner case); or require a later
protocol version (which seems to allow fetching specific items) and add
more logic to re-fetch anything which appears to be an incremental
update. Note: the latter is only based on my reading of the spec -- I
have not tested that it really works.