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

[Simon McVittie]

On Tue, 14 Aug 2007 at 09:20:08 +0100, Dafydd Harries wrote:
> 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

This looks suspiciously like dbus/proxies.py and its _ProxyMethod and
_DeferredMethod objects, which are returned after and before
introspection, respectively. Some pitfalls from that code:

* to avoid duplication you need to make an asynchronous call (always),
  then call block() on the resulting PendingCall object if necessary
* you can keep references to a _DeferredMethod after introspection has
  finished and this must be supported

I must admit, I think the __contains__ thing is an interesting
experiment, but I don't think it would be an undue burden on client code
that wants to do feature testing to have to call GetInterfaces() itself.
The dict-like access, if we keep it, could just hand you whatever
interface you want regardless. After all, we'll get an exception if you
use an unsupported one.

Perhaps we could have a wrapper, get_interfaces(reply_cb, error_cb) which calls
GetInterfaces() asynchronously and returns an object with a block()
method. It could optimize by only actually making the D-Bus call if the
interfaces have not already been fetched, else just calling the callback
with the already-fetched interfaces. For usability, it would be ideal if
the block() method returned the interfaces too and None was accepted as
a callback.

I'd like to do some work on telepathy-python (and eventually
dbus-python) to get this sort of thing into the code, but that's
unlikely to happen for a while. If you want to adopt my watch_*()
branch, please ask.

I think we should keep the current API working for a while, anyway -
we shouldn't gratuitously make API instability worse!

	Simon