On Wed, 2011-10-12 at 10:14 +0200, Patrick Ohly wrote: > On Thu, 2011-09-15 at 18:14 +0200, Lukas Zeller wrote: > > On Sep 12, 2011, at 14:16 , Patrick Ohly wrote: > > > > > On Sa, 2011-09-10 at 12:32 +0200, Lukas Zeller wrote: > > >> Hello Patrick, > > >> > > >> On Sep 7, 2011, at 14:53 , Patrick Ohly wrote: > > >> But what we could do is allow StartDataRead to return 508 error code > > >> to have the engine reset sync anchors before bailing out, such that > > >> the next session would become a slow sync. > > >> > > >> Would that solve the problem? > > > > > > It is sub-optimal because it will be visible to users. Currently > > > SyncEvolution doesn't automatically start a new sync. This will also > > > break the automated testing, which will bail out with that error instead > > > of doing a slow sync. > > > > > > As one way of dealing with the problem adding such a special error code > > > is worthwhile. But perhaps there is a different way? > > > > > > For example, could the datastore API extended with a "verify anchor" > > > call which is called soon enough to discard the anchor and fall back to > > > a slow sync? > > > > Officially adding API calls is very complicated due to the indirect > > way the plugin ABI is designed with all the up/downwards compatibilty. > > At least, I can't do that efficiently myself :-( > > > > But I think I found a better way to do the same, by simply allowing > > StartDataRead() to happen earlier - in time to cause a slow sync if > > needed. > > Your patched worked fine, after fixing one minor aspect. See attached > patch. > > This will allow me to close BMC #22881 after merging into the master > branches.
More testing after merging into the master branch led to a "want to have the cake and eat it" moment: invoking StartDataRead early is necessary so that the datastore can force a slow sync. But SyncEvolution also relies on seeing StartDataRead calls only after the first message exchange with the peer was successful and the credentials were accepted. Only then does it show a "sync started successful" message and does more expensive operations like dumping the datastore's data into the automatic backup. Now both of this happens too early and sometimes (in those cases where network is down or the login fails) unnecessarily. I guess the only proper solution would be a new CheckAnchor callback (invoked at the same time as StartDataRead with <plugin_earlystartdataread>) and then the real StartDataRead later (at the traditional place). How hard is it really to change the libsynthesis plugin API? It was meant to be extensible, wasn't it? As an intermediate solution I'll probably make SyncEvolution's use of <plugin_earlystartdataread> conditional: as before for most backends, early for ActiveSync (which is the only one which has the anchor problem). -- 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 os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
