On Mi, 2011-12-14 at 13:27 +0100, Chris Kühl wrote:
On Tue, Dec 13, 2011 at 4:04 PM, Patrick Ohly
> On Mo, 2011-12-05 at 12:12 +0100, Chris Kühl wrote:
>> I plan to do this work in 3 steps:
>> 1) The first step, which I've started, is to decouple the session and
>> server from each other and also modify objects that require both the
>> session and server objects as needed. Once this is done the server
>> should function as it does now and all tests should pass in order to
>> move on to step 2.
>> 2) Move session into separate binary using a one-to-one dbus
>> connection for communicating between the 2 processes. At this stage
>> only one session is run at a time and all tests should pass as before.
> I hate to interrupt your ongoing work, but can we reverse the steps so
> that we first introduce the helper executable and a way to start it,
> including the direct D-Bus communication with it?
Ok, I'm looking into this. The original plan was that Step 1 was a
dependency of Step 2 but I've been reconsidering my approach. I'll
look into what you're asking and get back to you soon.
One more thought about the various classes in the server and there
inter-dependencies: would it make sense to introduce signals+slots as a
way to connect the classes?
Boost.Signals would be the obvious candidate.
> I discovered end of last week that ActiveSync no longer works:
> apparently fork without exec leaves the forked process in a state where
> GIO gdbus is just blocking the caller without ever reaching activesyncd
> over D-Bus. That confirms that fork+exec is indeed needed.
If this is only happening with this combination, maybe it should be
disallowed for a very brief time until this is sorted.
It's the usage of GIO gdbus in activesyncd which is causing that, not
the GIO gdbus usage in SyncEvolution. activesyncd and its client
libraries switched unconditionally, so now SyncEvolution must adapt.
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.