Cleaning up the Python D-Bus Bindings

[Ray Strode]

Hi,

> reply_handler, error_handler sounds good to me.  It fits with the D-Bus
> terminology.  I was notified that interface might be part of the python
> spec at some point so interface will change to dbus_interface to keep
> consistent with dbus terminology and be name-spaced as to avoid naming
> clashes with python proper.
Okay sounds fine.

> Raise an exception.  This is a programing mistake.  For the most part
> async error handlers are for handling errors that come over the bus with
> a few exceptions.
ok.

> Whichever interface the user is going to use the most.  I don't think
> D-Bus enforces any policy of what gets used.  In fact using the lowlevel
> dbus API one can mostly ignore the interface.  According to the spec:
> 
> In the absence of an INTERFACE field, if two interfaces on the same
> object have a method with the same name, it is undefined which of the
> two methods will be invoked. Implementations may also choose to return
> an error in this ambiguous case. However, if a method name is unique
> implementations must not require an interface field.
> 
> So setting a default just specifies which interface to use if a method
> is not unique.
It's confusing though. if you don't want to specify an interface for
every method call it's only an extra line of code to use the Interface
class thing you proposed.  Let's just drop the extra parameter.  It
doesn't gain anything.

> Lets get rid of get_object and just use dbus.Interface to talk to
> objects just to make things more consistent.  It could be a static
> method that obtains an interface from a service or we could just check
> if the input to the constructor is a dbus.Service or another
> dbus.Interface.  In the first case it would look like this i =
> dbus.Interface.bind_service(service, "my.default.interface") or just i =
> dbus.Interface(service, "my.default.interface") the first is more
> descriptive but the second is cleaner.
This doesn't make sense because services don't implement
interfaces--objects do.  a service can export more than one object
that implements the same interface.

John and I talked about this off list and we decided the flow should
be something like:
dbus_name = "org.designfu.SomeName"
iface_name = "org.designfu.SomeInterface"
bus = dbus.Bus.get_session ()
obj = bus.get_object (dbus_name, "/path/to/object")

and then either:
obj.Method (paramaters, reply_callback=on_method_reply,
error_callback=on_method_error, dbus_interface=iface_name)

or optionally:
iface = Interface (obj, iface_name)
iface.Method (parameters, reply_callback=on_method_reply, 
                    error_callback=on_method_error)

> I don't like exposing object.remote as it just makes more typing for the
> user and is not intuitive.  Why not just resolve name clashes using dbus
> interfaces.  We can specify a standard interface for local calls like
> connect_to_signal.  If names clash we refer to the current interface to
> decide which method to call.  org.freedesktop.DBus.Python.LocalInterface
> or something like that.  We can always have a constant
> dbus.LOCAL_INTERFACE to reduce typing.
So rather than using org.freedesktop.DBus.Python.LocalInterface which
isn't useful across the bus, we decided to just say that if
dbus_interface=None then local methods take priority.  I still think
it's a bit confusing to put local methods and remote methods in the
same namespace but I think this is a reasonable compromise.