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.