Hello Patrick, On Sep 8, 2011, at 8:10 , Patrick Ohly wrote:
>> Status 207 is meant to indicate that the backend has added the item, >> but in the process merged the add with some additional data (from an >> external source, or another item in the sync set). So... > > What the backend really did was replace its own data entirely with the > data sent to it, with no merging involved at all. Therefore sending back > that same data is unnecessary and could be avoided. > > What we would need is another status "replaced existing item". Yes. After writing that mail, I realized that there could be cases where the backend detects a *perfect* duplicate or chooses for other reasons to replace its own data with the data sent with no field level merging (nor need for it). I'll add another status for that. > [...] Either that, or allow the case that an Add returns 200 with a LUID that > was > already in use before. The explicit status for it might be easier to > check for the engine. And more efficient in all non-conflict cases. >> No, that's the server updating the client with the result of the merge. >> >> Why would you expect this to be suppressed? On the contrary, this replace is >> explicitly forced by the 207 status handling code. > > With your explanation it makes sense. Ok. There are quite a few different possible reasons for wanting a merge and different modes for actually doing it :-) >> Maybe we can sort out why you were expecting something else, before I >> implement the "other half" > > With that "other half" implemented the redundant update can be avoided, > because the backend would stop using the 207 status and the engine can > determine itself whether the merged item needs to be sent back. It depends. The 207 mechanism is old and some users of the server engine rely on it, so that'll have to stay anyway. And I think a "replaced existing" would make sense as a logical extension to this. The "second half", i.e. delegating the actual merge process to the engine is something largely independent, and something that makes sense to offer for both server and client and both add and replace. Only in server add case, it also implies a 207-type post processing to make sure duplicates that may exist on the client get deleted. Best Regards, Lukas PS: I'm in the code now :-) _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
