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. Patrick, you were also mentioning that you'd like to rework the autosync mechanism. Shall I strip out that functionality from the server? Cheers, Chris _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
