Thanks Lukas, with your help I am now clear about what to do to support suspend and resume in SyncEvoltion.
Really appreciate! On Mon, 15 Jun 2009, Lukas Zeller wrote: > Hello Chen, > > On Jun 13, 2009, at 19:24 , Chen Congwu wrote: > > > I am still not definite on your message, I will repeat here hoping > > you can give > > me further clarification. > > > > Regarding the first part of your message, do you mean SyncEvolution > > doesn't have > > to change tracking MORE THAN ONE STATE per source since it is built > > with > > BASED_ON_BINFILE_CLIENT? If this is true, the current implementation > > in > > synthesis client is CORRECT, why do you think this is a conceptual > > bug? > > Maybe conceptual was not the correct word. The concept is ok, but I > guess I had some confusion between the DB side and the engine side > concept and believe there IS a problem insofar that the engine does > not always call StartDataRead() with the correct tokens. As said, I > have to check the details. > > > In my own understanding, the change log maintained by binfile glue > > layer is the > > synthesis client specific information (i.e. which items has been > > successfully > > sent, which items was not yet sent out or failed during sent out); > > while the > > change log maintained by SyncEvolution (DBplugin) is db specific > > information > > (i.e. which items has been changed since last time synthesis client > > asked for). > > Agreed. > > > Coming back to the suspend/resume support, assuming last sync is > > suspended. > > The question is: During next sync, does the synthesis client need > > *only* changes > > since last time her asked for SyncEvolution(last suspended sync)? > > Yes. > > > Or it needs *both* changes since last suspended sync and changes > > since last successful sync? > > No - not when built as BASED_ON_BINFILE_CLIENT. StartDataRead() has > two tokens ONLY for the case when the engine is NOT built as > BASED_ON_BINFILE_CLIENT, which is the case for all our servers and the > ODBC client. In these cases, the DB layer is responsible for all > change tracking. With BASED_ON_BINFILE_CLIENT, the change tracking > requirements for the DB is much simpler. > > > If the former is true, SyncEvolution only needs to change tracking > > *One* state; > > Correct. > > > if the later is true, SyncEvolution still needs to change tracking > > *Two* states. > > No, altough Patrick and me came to that conclusion in the initial > discussion, it is not needed. The binfileXXX layer makes this > unnecessary. > > > The spec says: After the suspended session, both the client and the > > server can > > refuse a resume, in that case a slow sync *must* be issued. This > > means during the > > next sync (after a suspended session), either a resuming session is > > issued or a > > slow sync. > > Yes, but that's a new requirement in SyncML DS 1.2.1. In 1.2, this was > not specified, and a server rejecting resume could well request a > normal sync. > I'm not sure why this was changed on 1.2.1. Technically there is IMHO > no reason why a rejected resume must be followed by a slow sync, as > long as the anchors are ok. One guess is that they tried to force > implementors of DS 1.2 servers to actually implement resume and not > fake DS 1.2 compatibility by simply rejecting all resume requests with > 509 and then continuing as if it was a normal sync (which a few did). > > > Therefore the server only needs changes before last suspended sync for > > resume! (Otherwise, during a slow sync, all the data will be sent to > > the server, > > no need for any change log). > > Two notes: > > 1) Consider the case where a client is synchronizing with more than > one server (all our PRO clients have multiple profiles). For that, > even without suspend&resume, you need a mechanism to pinpoint changes > on a time scale at multiple points, even more than 2 (if you have more > than 2 servers). That what the binfileXXX layer was created for in the > first place. > > 2) Even in a single server scenario resume, you must be able to > differentiate modifications happened after the original sync and > before the suspend and modifications happened AFTER the suspend. You > are right that this differentiation does not necessarily need a re- > evaluation of the changes since last regular sync as long as the > intermediate layer keeps a list of to-be-resent items somehow. > > Best Regards, > > Lukas Zeller ([email protected]) > - > Synthesis AG, SyncML Solutions & Sustainable Software Concepts > [email protected], http://www.synthesis.ch > > > -- Regards, Chen Congwu Moblin China Development _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
