On Thu, 2012-03-29 at 12:56 +0200, Krzesimir Nowak wrote:
[DEBUG syncevo-dbus-helper 00:00:00] exception thrown at
../../../projekty/cxx/syncevolution/src/syncevo/DevNullConfigNode.h:46
[ERROR syncevo-dbus-helper 00:00:00] : virtual read-only configuration
node, cannot write property sync = two-way
Fixed, I think:
commit 287cf501936fe06c3e2940bc22f16e3aae5fabd4
Author: Patrick Ohly <patrick.ohly(a)intel.com>
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>
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.