Status of dbus-python: more features

[Simon McVittie]

On Fri, 14 Aug 2009 at 10:03:51 +0200, Martin Vidner wrote:
> As I was refactoring cnetworkmanager, I added a wrapper around
> dbus-python:

I don't think the features you mentioned are generically applicable; some of
them are only possible to do properly in a library with domain-specific
knowledge (knowledge about the particular interfaces you're using, like
telepathy-python has, for instance).

It would be interesting to have code in dbus-python to simplify the writing of
such libraries, though.

> - it frees the user from specifying the interface for each call,
>   relying on the introspection data or on a default_interface
>   specified for a class

Using Introspect() *more* is the wrong direction, I think; it makes the
service able to crash you very easily, for a start, and if you don't know
what interface you're using (and need the service to tell you) then your code
is already wrong.

(If I had time to rewrite dbus-python, I think I'd avoid Introspect()
altogether and make signatures explicit... "import this" says "explicit is
better than implicit", after all :-)

> - it accesses properties as if they were dictionary members

I don't think we should be encouraging synchronous D-Bus calls: they're
tempting, convenient and wrong. See:
<http://smcv.pseudorandom.co.uk/2008/11/nonblocking/>

I think a better model for Properties is to download and cache the properties
of interest with GetAll (note that dbus-python can't know which interfaces
you're interested in, unless you tell it), and keep the cache up to date via
change notification signals (note that these are specified per-interface, and
don't necessarily exist at all, so dbus-python can't do this in a general way).

As a result, I think this is better done by domain-specific libraries that use
dbus-python (see telepathy-python, for instance, although that one is woefully
incomplete).

http://smcv.pseudorandom.co.uk/2009/05/tp-proxy/ explains the same sort of
approach applied to telepathy-glib and telepathy-qt4.

dbus-python *could* usefully gain code to make it easier to write those
domain-specific libraries, though (perhaps by subclassing and providing some
sort of declarative API description).

> - it wraps the calls to translate object paths to proxy objects,
>   integers to enumeration classes etc.

You can't, in general, know what bus name an object path is for. Several
Telepathy methods return a (bus name, object path) pair that points at an
object in a different process... so you can't necessarily construct the right
proxy in dbus-python. Other methods return only an object path, and the bus
name is obtained by a mechanical transformation of the object path
(typically object_path[1:].replace('/', '.')).

To do this right, you need domain-specific knowledge (again).

Regards,
    Simon