[Telepathy] telepathy-python: alternative approaches to client-side interface handling

Dafydd Harries dafydd.harries at collabora.co.uk
Tue Aug 14 01:20:08 PDT 2007

Currently, telepathy-python client objects subclass a class InterfaceFactory,
which overloads __contains__ and __getitem__, so that you can do, e.g.

  if telepathy.CONN_IFACE_ALIASING in conn:

The difficulty is that knowing which interfaces an object has requires calling
GetInterfaces() on it, but we would like it to be possible to do this
asynchronously since blocking calls are problematic. The current solution is
to pass in a ready_handler parameter to the Connection/Channel constructors,
but I think this leads to ugly code:

  def channel_ready_cb(channel):
      print "channel ready"

  def new_channel_cb(object_path, channel_type, handle_type, handle,
      Channel(conn.__service_name__, object_path,

  conn.request_channel(..., ready_handler=channel_ready_cb)

An alternative approach would be to get rid of the idea of objects being
"ready", and to implicitly do any introspection in conjunction with method
calls. When you look up an interface on a client object:

 - if introspection has been done already, use the cached interface list
 - otherwise, return a pseudo-Interface object that will perform introspection
   when you call methods on it
 - if you call a method synchronously, introspection is performed
 - if you call a method asynchronously, introspection is performed


 - overlapping asynchronous method calls need special handling
 - __contains__ will no longer work before you've called a method, unless it
   performs synchronous introspection (perhaps a has_iface_async() method
   would be ok)

In many cases, __contains__ could be replaced with exceptions:

  except telepathy.InterfaceError:
      # fall back

However, I think this is a loss in code clarity.



More information about the Telepathy mailing list