Re: [SyncEvolution] Memotoo refresh + empty data

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.

Try again and tell me.

> http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_db... > > 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_db... > http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_db... > > 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_db... > http://syncev.meego.com/2011-08-23-13-52_testing_davical_apple_memotoo_db... > > 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=45e61e6e17edaefdbe6aaae70ce...>)