Status of dbus-python: more features
simon.mcvittie at collabora.co.uk
Fri Aug 14 04:52:16 PDT 2009
On Fri, 14 Aug 2009 at 10:03:51 +0200, Martin Vidner wrote:
> As I was refactoring cnetworkmanager, I added a wrapper around
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:
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
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).
More information about the dbus