[RFC] dbus-python API (re)definition

[Robert McQueen]

Simon McVittie wrote:
> Comments?

This all sounds good. A few thoughts...

J5 mentioned he had some other objections to the public API as it stands
at the moment, if we could look at those as well that'd be good.

It would be nice if we had a way to export a python object as
representing an entire D-Bus object subtree, so that all of its methods
would be called with an extra object_path parameter, and you have an
exception you can raise if you want that object not to exist. Something
cunning about signal emissions too. :)

Client side we also have code in Telepathy which lets you do
proxy[INTERFACE].Method() to invoke stuff without bothering to keep
around pointers to seperate interface proxies. That'd be nice to see
included.

Currently if you import dbus.glib then it does some magic and sets up
bus connections for you with the mainloop. I'd like to see exceptions
get raised whenever you've not done this, and try to do something that
requires a mainloop (ie export an object, bind to a signal, make an
async method call) because this is without a doubt the single most
common error in using the bindings.

If we could set up dbus.loop or some other alternative which you can
import and just run a method to block on (similar to the proposed patch,
but I'd like to see it in a form that would pacify the above checking,
rather than just an ugly dbus.loop_until_the_cows_come_home()) that
would be good too.

>         Simon

Regards,
Rob

-- 
Robert McQueen
Director, Collabora Ltd.