Sorry for the delay of my answer ...
Le 24/08/2011 10:41, Patrick Ohly a écrit :
On So, 2011-08-21 at 15:00 +0200, Thomas Pequet wrote:
Le 19/08/2011 17:36, Patrick Ohly a écrit :
testDeleteAllRefresh:
1. four items in sync on client and server
2. client deletes all items, asks for refresh-from-client => no
items transferred
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?
OK now the four items will be deleted in server at 2.
I have modified Memotoo.
Confirmed, worked in the latests tests:
http://syncev.meego.com/latest/head-testing-amd64/nightly.html#memotoo
However, something else broke. Now "testDelete" fails for all data
categories. For example, contacts:
http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_dbus/head-testing-amd64/18-memotoo/Client_Sync_eds_contact_testDelete.log
The problem is an unexpected slow sync, instead of the desired two-way
sync. This is the same problem as for testOneWayFromServer, see below.
testOneWayFromServer:
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
I can not arrive to reproduce this test ...
My SyncEvolution send Data "200" instead of "204" for "one-way-from-server"
Sorry, I was looking at the wrong log (testOneWayFromClient instead of
testOneWayFromServer).
The client asks for a 202 sync in its Alert
(http://syncev.meego.com/2011-08-19-07-20_testing_memotoo/head-testing-amd64/18-memotoo/Client_Sync_eds_contact_testOneWayFromClient.send.client.B/syncevolution-log_trm001_001_outgoing.xml).
OK now Memotoo will return the anchor.
Still fails.
The latest test results for testOneWayFromServer are here:
http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_dbus/head-testing-amd64/18-memotoo/Client_Sync_eds_contact_testOneWayFromServer.log
The one-way-from-server sync is this:
http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_dbus/head-testing-amd64/18-memotoo/Client_Sync_eds_contact_testOneWayFromServer.recv.client.B/syncevolution-log.html
And here the message:
http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_dbus/head-testing-amd64/18-memotoo/Client_Sync_eds_contact_testOneWayFromServer.recv.client.B/syncevolution-log_trm001_001_outgoing.xml
Note that the Synthesis engine asks for a normal, incremental sync. I
suspect that it does the one-way sync like that by simply not telling
the server about its own changes.
The problem occurs when the sync has to fall back to a two-way slow
sync, because then items from the client do get sent to the server, in
contrast to the initial intention. IMHO this is a problem in the
Synthesis engine logic. But there's not much that can be done in that
case, except asking the users (as SyncEvolutions "prevent slow sync"
logic would do, if it was active).
The main problem is the fallback to a slow sync. Why does the server ask
for one?
I think it is because there is no data in sync history:
https://www.memotoo.com/configuration.php?rub=infoSyncML
Now if there is a "Last", Memotoo does not ask a slow sync.
Try again and tell me.
http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_dbus/head-testing-amd64/18-memotoo/Client_Sync_eds_contact_testOneWayFromServer.recv.client.B/syncevolution-log_trm001_002_incoming.xml
The client sent 20110823T194959Z as its last anchor and sc-pim-B as its
LocURI, which matches the values from the previous sync:
http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_dbus/head-testing-amd64/18-memotoo/Client_Sync_eds_contact_testOneWayFromServer.refresh.client.B/syncevolution-log.html
http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_dbus/head-testing-amd64/18-memotoo/Client_Sync_eds_contact_testOneWayFromServer.refresh.client.B/syncevolution-log_trm001_001_outgoing.xml
Between these two syncs there was another one from the client sc-api-A:
http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_dbus/head-testing-amd64/18-memotoo/Client_Sync_eds_contact_testOneWayFromServer.send.client.A/syncevolution-log.html
http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_dbus/head-testing-amd64/18-memotoo/Client_Sync_eds_contact_testOneWayFromServer.send.client.A/syncevolution-log_trm001_001_outgoing.xml
That also is an unexpected slow sync, but it doesn't show up as a
failure because the end result happens to be as desired. Normally
SyncEvolution's testing would check the sync mode and detect this, but
for Memotoo that is disabled because we had these cases where it did
unexpected slow syncs legitimately (no data on server).
Is it possible that the server doesn't properly distinguish between
multiple clients?
Normally Memotoo itendify the client with the "LocURI".
You can see if Memotoo does not identify the client and think it is
always "sc-pim-B" after "sc-api-A", with the RespURI and same sid (for
example:
<RespURI>http://sync.memotoo.com/syncML?sid=45e61e6e17edaefdbe6aaae70ce3fdb9</RespURI>)
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
