Python <--> d-bus <--> c++ woes

[Kip Warner]

On Mon, 2013-03-04 at 12:12 +0000, Simon McVittie wrote:
> On 01/03/13 02:20, Kip Warner wrote:
> > All of this happens via simple signals with no
> > need for advanced methods.
> 
> Adding some not-very-advanced method calls would make your code work
> considerably better :-)

Hey Simon. Thanks for getting back to me. It's really appreciated. I
took a while to respond because there was a lot of technical information
to digest with much of it I'm still trying to digest.

I don't know on how to add the method calls, unfortunately, and I find
the tutorials very cryptic and incomplete, in general.

> Note that the reference D-Bus implementation in libdbus is really very
> low-level. If you like GLib (which it seems you use in your Python code
> already), please look at GDBus (part of GIO since 2.26), which does a
> lot more of the hard work for you.

I've heard that suggestion before and I think you're probably right.

I would need to patch at least my project's configure.ac to find the
appropriate compilation settings which shouldn't be hard via pkg-config.
However, I am still confused about the difference between libdbus-glib
and GDBus. Is the latter a command line tool and the former the runtime
library that provides the GLib implementation of DBus? If so, I believe
I just need to query pkg-config with "dbus-glib".

Because my application runs off of a removable media, it compounds
problems because I have to ensure the needed runtimes are already
present on the most common distro's default environments. I think in
this case we are ok though.

> You could also use GDBus in your Python code (via "from gi.repository
> import Gio") as an alternative to dbus-python ("import dbus"): then
> you'd be using the same nice GObject-based D-Bus binding in both
> modules, albeit via different languages.

That's a good idea. I would like to do that, but I don't know anything
about the API you are recommended and I am worried about having to spend
days going through broken docs and incomplete tutorials to find which
specific python call I have to make, only to find that I need to go
through more hoops to get it to work with python 3. If it's as simple as
just changing the import with the signatures remaining the same, then
that would be awesome.

> > Next the C++ application is invoked.
> 
> I would advise you to look into D-Bus service activation: the technique
> used by things like Telepathy and gnome-terminal (among many, many
> others) to get services started automatically when a D-Bus client calls
> one of their methods. The short version is "write a .service file, then
> when your service starts, request the corresponding well-known name".
> 
> For instance <http://www.freedesktop.org/wiki/IntroductionToDBus> and
> <http://raphael.slinckx.net/blog/documents/dbus-tutorial> both reference
> service activation.

I've actually read both, but as far as I understand them, I'm worried
about a problem. Because my application runs off of a removable optical
media, activated via XDG's autostart on insert, the needed runtime
environment has to be setup via the disc's autorun.sh which invokes by
Python application on the disc which is in turn dependent on the user's
installed runtimes. As I understand it, the .service file needs to be on
the user's system already, correct?

> I think the C++ application should implement a method, and the Python
> application should call it. To avoid race conditions you might need two
> methods: call one to activate the C++ application, then connect to its
> signals, then call another method to say "OK I've connected my signal
> handlers, you're good to go".

I think that is another good idea, but I don't know on how to do that.

> Use GDBus. Seriously. :-)

I'd love to, but which packages do I need installed in order to use the
API on my distro (Xubuntu 12.04)? If it needs a runtime that doesn't
ship with the most common distros, then I can't use it.

> Failing that, it would be more conventional to use a main loop (e.g. the
> GLib one via dbus-glib), or to register a "filter function" to receive
> messages then call dbus_connection_read_write_dispatch() to "turn the
> handle" on the D-Bus connection.

That sounds incredibly complicated to tell a program to start doing
something, but I'll give it a shot.

> If you used a method call instead of a signal, and made the C++ part
> send a reply to that method call when it processes it, then the Python
> code would always get a reply: either an error from the dbus-daemon,
> essentially saying "the C++ part isn't running", or a successful reply
> from the C++ part. This would make it easier to diagnose what's going on.

I like the method idea, I just don't know how to do it.

> I don't immediately see why you get a 20 second delay or message loss.

Well I suppose it would only be an issue if it remains after converting
the Python code to call a method and the C++ application to implement
one.

Thanks a lot for your help.

-- 
Kip Warner -- Software Engineer
OpenPGP encrypted/signed mail preferred
http://www.thevertigo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/dbus/attachments/20130306/29da1e2e/attachment.pgp>