Re: [SyncEvolution] server class + fork/exec dbus-server + command line testing

On Thu, 2012-03-29 at 12:56 +0200, Krzesimir Nowak wrote: Fixed, I think: commit 287cf501936fe06c3e2940bc22f16e3aae5fabd4 Author: Patrick Ohly <patrick.ohly(a)intel.com&gt; Date: Fri Mar 30 14:30:21 2012 +0200 D-Bus server: fixed running a sync inside a command line session CmdlineWrapper::createSyncClient() must pass a valid config name, taken from the base Cmdline, to the DBusSync. Otherwise the sync runs without access to a writeable sync config, leading to errors about "virtual read-only configuration node, cannot write ..." I've also experimented with output handling. Not done yet: commit 40e29611476b6d7c048382f27eb5e7c5a134f72d Author: Patrick Ohly <patrick.ohly(a)intel.com&gt; Date: Fri Mar 30 14:58:12 2012 +0200 D-Bus server: handle syncevo-dbus-helper output This is a first shot at making the user-visible output created during operations visible to the user again. It's based on the same idea as output handling in the syncevo-dbus-server: - Session registers itself as the top-most logger and sends SyncEvolution logging via D-Bus to the parent, which re-sends it with the right D-Bus object path as output of the session. - Output redirection catches all other output and feeds it back to the Session log handler, from where it goes via D-Bus to the parent. The advantage of this approach is that level information is made available directly to the parent and that message boundaries are preserved properly. The disadvantage is that the current solution is racy: depending on the order in which events are processed, the command line client quits before it has printed all output from the helper. This needs further work... A better solution might be to capture stdout and stderr in ForkExec.cpp, translate it back into messages and relay that to the command line client. That would be guaranteed to capture everything happening inside the helper. I'll be away next week, so I'll put this aside for now. -- 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.