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. _______________________________________________ Telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
