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