On Tue, Feb 7, 2012 at 8:19 PM, Patrick Ohly <[email protected]> wrote: > On Tue, 2012-02-07 at 12:44 +0100, Chris Kühl wrote: >> On Tue, Feb 7, 2012 at 9:23 AM, Patrick Ohly <[email protected]> wrote: >> > On Tue, 2012-02-07 at 09:04 +0100, Murray Cumming wrote: >> >> On Tue, 2012-02-07 at 03:35 +0100, Chris Kühl wrote: >> >> > Yeah, unfortunately things are not ideal. Have you given any further >> >> > thought as to how we are going to properly detect conflicting sync >> >> > sessions? This points getting close that this is going to need to be >> >> > dealt with. I've not looked into this at length yet. Is there no >> >> > interface I could use to test that syncs will not conflict? >> >> >> >> Nevertheless, it would be nice to punt this to a later patch/branch, >> >> just so we have some chance to get the current work into master. >> > >> > I agree. Let's keep the current behavior (only one session can run at a >> > time) and figure out how to detect non-conflicting sessions later. Don't >> > bite off more than you can swallow :-) >> > >> >> Ok, I'll reimplement the queue then. >> >> I was thinking that with an interface in place I could actually have >> the code in-place that would do the concurrent sessions even if now it >> would always return that there is a conflict. For testing that >> concurrent sessions do actually work with known, non-conflicting >> sources, we could introduce an environment variable that would return >> that there is no conflict. That way, as soon a solution is found ofr >> finding conflicts, is should just work. > > That makes sense. >
Ok, should have this set up today. >> Patrick, you were also mentioning that you'd like to rework the >> autosync mechanism. Shall I strip out that functionality from the >> server? > > Please ifdef out or comment any code which no longer compiles, but keep > it in place. I'll have a look this week. > Compiles fine so far. Just seemed like you weren't really enthusiastic about it and it seems that 2 of the 3 scenarios where it's designed to be used are not implemented. I'll leave it as is. > The core decision making still belongs into the main > syncevo-dbus-server. That's the right place to track when sessions ran > and are meant to run again. > Agreed, and everything should be that way now. The helper process just waits for commands, syncs and sends status and progress signals to the server process. Cheers, Chris _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
