Implementation of an async method in Python DBus

Question

How do I implement an async method in Python DBus? An Example below:

class LastfmApi(dbus.service.Object):
    def __init__(self):
        bus_name = dbus.service.BusName('fm.lastfm.api', bus=dbus.SessionBus())
        dbus.service.Object.__init__(self, bus_name, '/')

    @dbus.service.method('fm.last.api.account', out_signature="s")
    def getUsername(self):
        ## How do I get this method done asynchronously ??
        ##  For example, this method should go off and retrieve the "username"
        ##  asynchronously. When this method returns, the "username" isn't available
        ##  immediately but will be made available at a later time.

I am using Twisted's glib2 reactor.

Update: I know this behavior is possible to implement - DBus includes a "serial" (unique identifier) to method calls and the called method has access to this identifier in order to match "calls" with "replies".

Answer 1

I haven't tried this, but reading the documentation for dbus.service.method reveals the async_callbacks parameter. It sounds like one uses this parameter to provide an asynchronous result. For example:

@dbus.service.method('fm.last.api.account', out_signature="s",
                     async_callbacks=("callback", "errback"))
def getUsername(self, callback, errback):
    reactor.callLater(3, callback, "alice")

If, instead, you have an API which returned a Deferred, then you can easily associate the Deferred with these callbacks:

d.addCallbacks(callback, errback)

As far as the correlation between call and response goes, I assume that all the serial number handling is hidden inside dbus.service.method. I suspect that the callback and errback functions that are passed in when you use the async_callbacks feature are either instances of some class which is callable and has the serial number as an attribute, or else are defined as nested functions and close over the serial number. This way, when you call one of them, they can make sure to pass the right value back to the connection to associate the response with the original request.

However, that's just a slightly educated guess based on your mention of serial numbers and my experience with implementing various async systems. :) A read of the implementation of dbus.service.method would probably reveal the actual strategy without too much pain.

(Okay, I actually went and looked at the implementation now, and unfortunately it's rather complicated, and I lost the trail when it got to some code that's defined in the C-level dbus bindings, which is a bit more digging than I'm interested in doing. I still suspect the general idea I described above is correct, but the details of the implementation are more involved than I expected.)