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

2012/3/30 Patrick Ohly <patrick.ohly(a)intel.com&gt;: > 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&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. Neat, and found why I had GConf errors - I was compiling syncevolution under jhbuild, because system's GLib was too old (racy GDBus). I guess that some parts of jhbuilded libs were not cooperating with system libraries. For now I switched to bluez wrapper.

> I'll be away next week, so I'll put this aside for now. Yeah, me too. Have a nice holidays then. > > -- > 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. > >