On Sep 8, 2011, at 8:10 , Patrick Ohly wrote:
> Status 207 is meant to indicate that the backend has added the
> 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
> 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.
PS: I'm in the code now :-)