On 06. aug. 2012 12:23, Patrick Ohly wrote: > On Sat, 2012-08-04 at 02:22 +0200, Ove Kåven wrote: >> Den 15. juli 2012 15:27, skrev Patrick Ohly: >>>>> should solve the problem. >>>> >>>> What is it supposed to do instead? >>> >>> ITEM_OKAY if add or update worked as requested, ITEM_REPLACED if the >>> engine asks for adding the item (luid empty) and the incoming item has a >>> UID/RECURRENCE-ID property which matches an existing item, in which case >>> the backend has to turn the "add" into an "update" to avoid >>> UID/RECURRENCE-ID conflicts. >> >> Well, I should probably also update the N900 (Maemo) backend. From what >> I can tell from the calendar-backend sources, when it detects a >> duplicate, it compares the last-modification times, and if the new entry >> is newer, it replaces the old entry. > > How does the backend detect duplicates? I thought it didn't support UID > +RECURRENCE-ID. Some heuristic?
Heuristic, I suppose. For example, for events, it seems to check whether there's an entry with e.g. the same summary/description text, location, and start time. (There seems to be some code to also check some kind of uid, if it exists, but this is probably not the same as the icalendar UID, if that check is even used - I haven't found anywhere that this particular uid field is ever set. Was probably just never implemented.) >> But if the backend keeps the >> existing entry and discards the incoming one, what should insertItem >> return to SyncEvolution? > > Use ITEM_REPLACED and return the ID of the existing item, regardless > whether the item was stored or not. ITEM_MERGED would mark the existing > item data for later transmission (well, if it worked on the client > side...), which should not be necessary in this case because the > add/update of that item should have been reported already earlier. Hmm, OK. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
