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! 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. _______________________________________________ SyncEvolution mailing list [email protected] https://lists.syncevolution.org/mailman/listinfo/syncevolution
