Great, thanks Lukas. Thanks, Chen,Congwu
>-----Original Message----- >From: Lukas Zeller [mailto:[email protected]] >Sent: Thursday, June 18, 2009 7:09 PM >To: Chen, Congwu >Cc: Synthesis >Subject: Re: [os-libsynthesis] Synthesis client does not save suspend >identifier > >Hi Chen, > >I just finished cleaning up the changelog tracking code - it's now >pushed to indefero git, see >http://www.synthesis.ch/indefero/index.php/p/libsynthesis/source/commit/8 >c456223b0e9387ff96106cb699868dba44b77db/ >for details. > >With this, a DB backend tracking changes since one single reference >point should now work correctly. > >Best Regards, > >Lukas > > >On Jun 15, 2009, at 3:06 , Chen Congwu wrote: > >> 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 >> > >Lukas Zeller ([email protected]) >- >Synthesis AG, SyncML Solutions & Sustainable Software Concepts >[email protected], http://www.synthesis.ch > > _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
