|
From: Daniel G. <dg...@su...> - 2008-02-13 15:11:25
|
On Wednesday 13 February 2008, Michael Bell wrote: > > I'm quite sure (without checking the code) this is the root cause. SyncML > > plugin flags the Main Sink to perform a SlowSync (since the connect > > function detect an anchor mismatch). > > No, this is wrong. The SyncML plugin flags the object sink to perform a > slow-sync but this can happen sometime after get_changeinfo was called > (please see _ds_*_recv_alert). Arg, i see. This might cause further problems. Isn't it possible to gain the Anchors value in the connect sink functions? But i can also reliable reproduce my first investigation :( I guess then we have to reintroduce ObjTypeSink specific connect functions for the SyncML plugin. Maybe it's possible to have the main sink connect function to perform the transport connect. And use the ObjTypeSink connect function to gain the anchors value... > > > BUT the slow-sync flag on the main-sink doesn't affect the other sinks. > > So the file-sync plugin will never get asked to perform a slow-sync if > > this got triggered by a plugin which is using a main-sink function (like > > the SyncML plugin). > > I think that the slow-sync flag is simply set too late for the other > plugins. If the file-sync function get_changeinfo is called first > (because it is the first group member) then it is too late for all other > plugins to set the slow-sync flag. It's not only about the first group member, all sink functions of the members/plugins get called in a sequence but in an async way. So they doesn't block... and get called nearly simultaneously. So the slowsync flag has to be set within the connect() functions. > > The solution would be to put the alert handling into some new functions > (like get_syncmode) and register them as connect functions for the > object sinks. The "problem" is that we have to break up again the > complete SyncML plugin code. Correct. As long it's only the plugin not the entire OpenSync framework ;) best regards, Daniel |