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. > 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. 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. -- 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
