On Sa, 2011-03-05 at 17:06 +0000, Thomas Pequet wrote: > Thanks Patrick > > I have seen that the device > "syncevolution-3b3d8d41-71db-477b-b91a-08600a31cd93" (the 2nd) sync > only "Evolution -> Memotoo" in Memotoo: > https://www.memotoo.com/configuration.php?rub=infoSyncML&id=50113
Each test session starts with random device IDs, as if the user had started using MemoToo for the first time. Is this "SyncEvolution -> Memotoo" setting the default for new devices? Does it mean that all users who want to download data from Memotoo need to reconfigure their account? Does it apply only to *updates* during a two-way sync? *New* items seem to get transferred (but that might be during a slow resp. refresh-from-server sync). I also noticed that only calendar items were affected. The test passed for contacts - shouldn't it also fail for those? I'll change the testing to use fixed device IDs now, and try again. Hmm, didn't work. I used the "syncevolution" account, device IDs sc-api-A and sc-pim-B. The test fails, but the web interface shows "both ways" for these two devices and calendar events. The synchronization history for "sc-api-A" shows: phone meeting SyncEvolution ยป Memotoo : Add 2011-03-06 - 16:35:42 (G.M.T. +1) There should also be a later entry for *updating* that item. To me it looks like the server ignores the Replace command from the first client (sc-api-A in this case): https://www.memotoo.com/configuration.php?rub=infoSyncML&id=50476 The data on the server definitely is the older item, not the update. -- 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
