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:
conn[telepathy.CONN_IFACE_ALIASING].DoSomething(...)
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,
suppress_handler):
...
Channel(conn.__service_name__, object_path,
ready_handler=channel_ready_cb)
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
synchronously
- if you call a method asynchronously, introspection is performed
asynchronously
Difficulties:
- 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:
try:
conn[telepathy.CONN_IFACE_ALIASING].RequestAliases(...)
except telepathy.InterfaceError:
# fall back
However, I think this is a loss in code clarity.
Thoughts?
--
Dafydd
_______________________________________________
Telepathy mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/telepathy