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? > 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. -- 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] http://lists.syncevolution.org/listinfo/syncevolution
