[Telepathy] Proposed Telepathy client GLib API
xclaesse at gmail.com
Wed Oct 17 04:57:02 PDT 2007
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).
> * 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
> * 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
> * 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
* TpChannel should have a "connection" property that returns a
* cache as much as possible: group members, handle's name, channel interfaces, etc.
Thanks for working on that!
More information about the Telepathy