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. _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
