[RFC] dbus-python API (re)definition

[Simon McVittie]

On Tue, 05 Sep 2006 at 19:51:43 -0400, Havoc Pennington wrote:
> If someone's asking, can I create a well-defined way to change my 
> interfaces, by e.g. having an API where objects can be "withdrawn," or 
> emit an InterfaceChanged signal, or whatever; then sure, go for it. I 
> think there's no reason this isn't allowed, though I also don't know why 
> you would do it offhand.

This is the situation we have in Telepathy: we have objects
representing a connection to an instant messaging server, which
implement an interface Connection, and possibly some other interfaces
like Avatars, depending on server capabilities.

On some IM protocols (Jabber/XMPP, at the moment) we want to advertise a
varying set of interfaces depending on what this particular server supports,
but we can't actually tell that until the connection has changed state to
"Connected". A new Connection isn't actually connected yet, to avoid a race
condition that used to exist (you couldn't attach a signal handler until
you'd asked the ConnectionManager for the object-path of a new
Connection, and since doing so used to trigger a connection attempt,
this may have been be too late to see all the state changes). Instead, you
have to set up signal handlers, then call Connect() (on the Connection
interface).

(I won't be offended if you think this is a mad design - I didn't design
it, and the originator of this idea is still somewhat undecided about it!)

At the moment we just have a GetInterfaces() method returning the
"extra interfaces" supported by the Connection, as strings - I agree we
should add some sort of InterfacesChanged signal, or add the
list of interfaces to the information emitted in the StateChanged
signal.

On the client side, in our Python bindings we support the Connection object
with a proxy wrapper that maintains a set of supported interfaces, and
allows this syntax to obtain a dbus-python Interface object:

	connection['org.freedesktop.Telepathy.Connection']

I'd like to introduce this syntax into dbus-python's proxy class, as a basic
implementation that either believes it supports every interface (leaving the
service-side to raise an error when the client tries to call a method), or
uses introspection to list its interfaces at instantiation. We could then
subclass this in telepathy-python (and any other project in the same
situation) for those objects that have a specific way to find out about
interface changes.

	Simon