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.
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.