Hello! SyncEvolution's ActiveSync backend is the first one which uses the string tokens in StartDataRead() and EndDataWrite(). The backend always runs inside a binfile-based SyncML client.
In one particular test I am using a "one-way-from-server" sync, initiated by the client, and noticed a problem: the new token created by the backend in EndDataWrite() was not passed to the StartDataRead() in the next sync. The backend cannot handle that, because the tokens come directly from ActiveSync, which only allows reusing old tokens in a few limited cases. In this case, the server rejected the obsolete token, causing an unexpected slow sync. Full log is here: http://syncev.meego.com/2012-08-16-17-03_all/testing-amd64/14-exchange/Client_Sync_eds_contact_testOneWayFromLocal.send.client.B/syncevolution-log.html It has no debug output explaining the problem. I tracked it down to this: // save end of session state localstatus TCustomImplDS::implSaveEndOfSession(bool aUpdateAnchors) { localstatus sta=LOCERR_OK; PDEBUGBLOCKCOLL("SaveEndOfSession"); // update TCustomImplDS dsSavedAdmin variables (other levels have already updated their variables if (aUpdateAnchors) { if (!fRefreshOnly || fSlowSync) { ... // also update opaque reference string possibly needed in DS API implementations fPreviousToRemoteSyncIdentifier = fCurrentSyncIdentifier; => PDEBUGPRINTFX(DBG_ADMIN+DBG_DBAPI+DBG_EXOTIC,("updating sync token (fPreviousToRemoteSyncIdentifier) from %s to current sync token %s",fPreviousToRemoteSyncIdentifier.c_str(),fCurrentSyncIdentifier.c_str())); } else { => PDEBUGPRINTFX(DBG_ADMIN+DBG_DBAPI+DBG_EXOTIC,("keeping old sync token (fPreviousToRemoteSyncIdentifier) %s instead of updating to current sync token %s",fPreviousToRemoteSyncIdentifier.c_str(),fCurrentSyncIdentifier.c_str())); } I added that debug output. It confirms that the "keeping old sync token" branch is taken. What is the rationale here? Is the goal perhaps that if the client switches back to a two-way sync, all changes since the last two-way sync get sent, despite the intermediate one-way sync? Those changes include the changes made on behalf of the server during the one-way-from-server sync. Is that filtered out? My test is probably broken. IMHO one-way sync only makes sense into a storage which never changes on the receiving side. In the ActiveSync case, that cannot be guaranteed, so I might as well just skip the test. OTOH, a user might decide to use an ActiveSync server as remote backup, in which case one-way syncing makes sense again. Would it be acceptable to always take the "updating sync token" branch above? -- 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. _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
