--
A bientôt sur Memotoo !
Thomas Pequet - Webmaster Memotoo
See you soon on Memotoo !
Thomas Pequet - Webmaster Memotoo
https://www.memotoo.com/profile/thomas.memotoo
On Mo, 2011-09-12 at 09:56 +0200, Thomas Pequet wrote:
Le 24/08/2011 10:41, Patrick Ohly a écrit :
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.
I don't understand. This was not the first sync; I linked to the
previous sync session in my email. Did you look at the examples and
conclude that the server believes that the sync is the first one?
With the examples, I think that Memotoo think it is the first sync.
So now, if there is a "Last" value, Memotoo will know that is not the
first sync.
Try again and tell me.
I've tried this repeatedly, it was reproducible. Unless you changed
something, it is going to continue to fail. But I can try again.
Yes I have changed something.
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>)
In other words, the sid is always the same for each client?
No it is available for the time of the session. But if you see the same
sid value when you sync "sc-pim-B" and "sc-api-A", there is a problem. I
think it will do not arrive.
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
