Hello! In SyncEvolution, we have two open issues which are both related to the way how the engine selects the sync mode when running as server.
The first one is around not recording the final sync mode (http://bugs.meego.com/show_bug.cgi?id=2786). As a client, a PEV_ALERTED progress event is emitted, but not for a server. Conceptually it would be wrong, although the information conveyed in it would be the same: /** datastore alerted (extra1=0 for normal, 1 for slow, 2 for first time slow, extra2=1 for resumed session, extra3=syncmode: 0=twoway, 1=fromserver, 2=fromclient) */ PEV_ALERTED = 19, The second issue is about not detecting when we have to fall back to a slow sync unexpectedly (http://bugs.meego.com/show_bug.cgi?id=619). Similar to that is the third one, dealing with clients we asked to do a refresh-from-server who then do a normal two-way sync instead (http://bugs.meego.com/show_bug.cgi?id=2722). In the "detect slow sync" thread here on this list we came to the following proposal (from Lukas): > In that light I wonder if it wouln't be easier and cleaner to > introduce a new session-level <initcompletescript> which would run at > the point the initialisation package ends (that is, when the <final/> > for that package is detected), which would have the final say about > continuing the session or not. That script could check session vars > for that decision which could be set from datastore level scripts. On > that level, I'd also add an additional <alertcompletescript> that > would be called after processing the alert and figuring out if a slow > sync is needed. That would be the place to check for the unwanted slow > sync condition and set a session var flag that <initcompletescript> > could catch. Lukas, if you can provide me with some pointers into the source, then I can give it a try to implement these new scripts. Would the <alertcompletescript> source code location also be a good point to emit a PEV_ALERTED event from the server side? -- 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
