On Do, 2011-08-18 at 15:22 +0200, Thomas Pequet wrote:
If I remember that we said... When you do a refresh-from-client and
there is no data in Memotoo, Memotoo ask a slow sync ...
Why force a slow sync in this case? A refresh-from-client has the exact
same effect, whereas forcing a slow sync confuses the client because it
cannot tell whether something went wrong or the server is simply empty.
The "prevent unexpected slow sync" feature in SyncEvolution doesn't work
with Memotoo because of this.
If I remember correctly, the logic rather was "if the server is empty,
always do a slow sync, regardless of the mode requested by the client".
The justification was that if the user wipes out all data on the server
via the web UI, he expects to get all data from the device instead of
also removing the data on the device in the next two-way sync.
I still don't buy that argument because there are better ways of
achieving it (when resetting the server, reset sync anchors), but that's
just my preference.
Anyway, I reran all tests for contacts and some of them fail with
unexpected behavior by the server:
1. four items in sync on client and server
2. client deletes all items, asks for refresh-from-client => no
3. slow sync to verify => four items recreated on client
The server seems to have ignored the request to delete its data before
syncing in step 2. Is that intentional?
testRefreshFromClientSync: succeeds because the client doesn't really
check the semantic of the operation, only the sync mode.
testRefreshFromClientSemantic: exactly the same as testDeleteAllRefresh
- I wonder whether the test should be modified to test something else,
like replacing the server data with some other local data.
1. client A, B and server empty
2. client A add one item, sends to server
3. client B adds one item locally, does one-way-from-server
Instead of the one-way-from-server sync, the last step ends up doing a
slow sync because the server sends an empty sync anchor. Then the client
sends its one item (which it wouldn't normally do in a
one-way-from-server sync) and later the server asks the client to delete
that item (which again wasn't meant to happen).
The expected outcome would have been that the one new item on the server
gets added to client B, while the new item on client B remains there
(not deleted, not sent to server).
The client asks for a 202 sync in its Alert
Why does the server accept that and then send an empty anchor?
The previous sync with client B is here:
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.