Hello Patrick, On 21.08.2012, at 09:28, Patrick Ohly <patrick.o...@intel.com> wrote:
> 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. > > [...] > > 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? Exactly! Changes made on the updated-only side must not be forgotten, so the reference point for syncing BACK data is the last sync where data is sent to the remote (hence fPreviousTOREMOTESyncIdentifier). A update-from-remote is not a To-Remote-Sync, so the identifier is not updated. > Those changes include the changes made on behalf of the server during > the one-way-from-server sync. Is that filtered out? The binfile implementation does some filtering of changes done by sync vs real changes (chgl_modbysync flag), although I'm not 100% sure it would cover this case correctly; it was implemented for suspend&resume which has a similar challenge (partial syncs bring in new data, but the token cannot be updated until the sync has completed). But that particular code you were looking at long predates binfile. The original idea was that it is better to reflect back too many changes to the server than loosing client data or getting out of sync at a switch from "update device" back to "two way". > 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? Yes, I guess that could be added as an option. To make it clean, a application using that options should make sure a switch back to "two way" also forces a slow sync; otherwise the resulting state could be out of sync (changes left on one side alone indefinitely even after a seemingly complete and successful two-way sync). Best Regards, Lukas Zeller, plan44.ch l...@plan44.ch - www.plan44.ch _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
