Re: [SyncEvolution] 409 "item merged" in client
On Mon, 2012-01-30 at 18:04 +0100, Patrick Ohly wrote:
Should it have removed one item while processing the <Map>?
IMHO it can't, because it doesn't have enough information to determine
which of its two items are up-to-date. It only knows that the client
must have merged two items, but not yet which one won.
In the second session, the server gets an updated item with client ID
"foo". Now it could update one copy and delete the other, but because it
only kept a link between its item 0 and foo, it only does the update
part.
Would something break if the server allowed the same client item to map
to multiple items on the server and then did a remove in its database
when receiving an update?
I suspect that the client is simply doing something not expected by
typical SyncML servers.
I'm currently experimenting with a different approach for handling the
409 in the binfile client: when an Add fails with 409, catch it as it is
done at the moment, but then tell the server that it was mapped to a
dummy LUID. Mark that LUID as deleted in the change log. Then in the
next session, delete the redundant item on the server.
I'm combining that with running multiple SyncML sessions in the same
context.
Will post code soon...
--
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.