On Mi, 2011-12-14 at 16:52 +0100, Chris Kühl wrote: > On Wed, Dec 14, 2011 at 4:25 PM, Patrick Ohly <patrick.o...@intel.com> wrote: > > On Mi, 2011-12-14 at 15:44 +0100, Chris Kühl wrote: > >> >> 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. > >> > > >> > I can also do that part myself, if you give me some pointers to > >> relevant > >> > technical documentation. I was looking for information on > >> bootstrapping > >> > a D-Bus connection over a pair of connected file descriptors, > >> without > >> > much luck. > >> > > >> > >> Well, in GIO GDBus you can create a connection using a GIOStream using > >> g_dbus_connection_new_sync(). Not sure if that would really work the > >> way you want, though. > > > > Looks promising. > > > > How about the same thing for libdbus? > > > > I just looked but don't see anything.
We need it in the case where GIO GDBus is not yet available. dbus_server_listen() and dbus_connection_open_private() probably can be used. > If you are referring to setting > up a peer-to-peer dbus connection, that's done using the (G)DBusServer > class. There is an example at [1]. That's a starting point, although it still needs to be done differently for libdbus+GDBusCXX. > Also, I intend to use g_spawn [2] for the fork and exec'ing. Should > offer enough control and make for less code to maintain. Okay. > >> I've no problem doing this, though. > > > > I don't care either way, as long as we can get it done soon, like this > > week ;-) > > > > That might be a little tight. Tomorrow is a short day for me; Xmas > party at the Kindergarten my kids attend. So, maybe it's better you > tackle this if you need it that fast. Yes, let me see how far I get. That'll allow you to continue with your original plan, too. -- 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. _______________________________________________ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
