Re: [SyncEvolution] one-way sync + sync tokens not updated
Hello Patrick,
On 21.08.2012, at 09:28, Patrick Ohly <patrick.ohly(a)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
luz(a)plan44.ch - www.plan44.ch