On Tue, Feb 7, 2012 at 8:19 PM, Patrick Ohly <patrick.ohly(a)intel.com> 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 <patrick.ohly(a)intel.com> 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