[Telepathy] Proposed Telepathy client GLib API

[Xavier Claessens]

Hi,

Le mardi 16 octobre 2007 à 16:28 +0100, Simon McVittie a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Rob and I have been thinking about how best to improve the client API
> of Telepathy. We want to include some sort of client-side code in
> telepathy-glib, so we can declare libtelepathy to be obsolete. In the
> process we want to fix libtelepathy's API problems.
> 
> We'd appreciate comments on this, particularly from client code authors
> (Empathy, Tapioca, Banter, Nokia Mission Control and UI, Decibel).
> 
> Goals:
> * All "boring" code auto-generated from the specification, like we do
>   for services, to avoid mistakes while improving type-safety
> * Easier to use than libtelepathy
> * Clean, consistent API that does not expose implementation details, so
>   it can be reimplemented in a more efficient way without ABI breakage
> * Easy synchronous and async calls, with async encouraged
> 
> Non-goals:
> * Replacing dbus-glib
> 
> Here's what our plan for the API looks like:
> 
> * TpClientProxy is a subclass of DBusGProxy with logic for fetching and
>   caching a list of interfaces
> 
> * TpChannel, TpConnection, TpConnectionManager are the main subclasses of
>   TpClientProxy
> 
> * TpMediaStreamHandler, TpMediaSessionHandler, TpChannelHandler are also
>   TpClientProxy subclasses? or direct DBusGProxy subclasses?
> 
> * Auto-generated method stubs similar to those in libtelepathy's *-gen.h in a
>   tp_cli namespace, with naming similar to the tp_svc namespace, leading to
>   names like tp_cli_connection_interface_avatars_get_avatar_requirements -
>   instead of taking an interface DBusGProxy as the first argument, they
>   will probably take the main proxy (TpConnection etc.) as the first argument

Really good idea! But how will I connect signals, I need to get
interfaces proxies for that... Or maybe we could have
tp_cli_channel_connect_signal (tpchan, interface, signal, cb, userdata);

> * Hand-written convenience methods outside the tp_cli namespace added
>   on an as-needed basis, e.g. tp_cli_connection_request_channel() will
>   "return" an object path, but tp_connection_request_channel() will return
>   a TpChannel. Some of these methods will cache data where it's known to
>   be safe, listening to signals where necessary to keep the cache fresh.
>   For instance, group membership can be tracked like that, and handle
>   inspection can probably be cached.

EmpathyTpGroup already cache information, would be really great if it
could be done in tp-glib!

> * Some sort of really cunning signal-connection process that I haven't quite
>   planned out yet :-)

Things I would like to have for a client point of view:
 * Easier CM crash handling. Maybe we can have on TpChannel a signal
emitted when either the proxy is destroyed or the channel is closed, for
clients it's the same.
 * Disconnect dbus signals when TpConnection/TpChannel are finalized.
 * A property on TpChannel to close the channel when the object is
finalised.
 * TpChannel should have a "connection" property that returns a
TpConnection.
 * cache as much as possible: group members, handle's name, channel interfaces, etc.

Thanks for working on that!

Xavier Claessens.