[Telepathy] Proposed Telepathy client GLib API
Luiz Augusto von Dentz
luiz.dentz at gmail.com
Tue Oct 16 12:31:42 PDT 2007
On 10/16/07, Simon McVittie <simon.mcvittie at collabora.co.uk> wrote:
> * 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
I would add:
* Thread safe or multi-threaded.
> * Replacing dbus-glib
Not sure what you mean, but you simply cant just ignore its problems, or you
simple want to create another library after dbus-glib is deprecated?
> 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
> * 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.
> * Some sort of really cunning signal-connection process that I haven't quite
> planned out yet :-)
Well this really sound a lot like what we have in tapioca-glib, but I
you provide some good library for mission control spec (if there is any to be
consider a standard).
Btw, TpaObject does have a mechanism to connect and auto-diconnects dbus
signals, perhaps you can have a TpClientObject so it handle common dbus code
or TpClientProxy may be able to do that for you.
> Meanwhile, Rob will continue to convert Stream Engine into library code, in
> the tp_media namespace. This will initially depend on libtelepathy, but
> when telepathy-glib has enough client code to support Stream Engine,
> it'll use telepathy-glib instead. This library will eventually be moved to
> the telepathy-glib Darcs repository (possibly in a telepathy-media-glib
> subdirectory); when it's API-stable, it'll produce
> libtelepathy-media-glib.so.0. We expect distributions to package
> the two libraries separately, e.g. Debian would ship binary packages
> libtelepathy-glib0 and libtelepathy-media-glib0, both built from a source
> package called telepathy-glib.
> The division between telepathy-glib and telepathy-media-glib is that
> telepathy-media-glib contains everything that requires Farsight. If
> Farsight is not available at build time, only telepathy-glib will be
> built. Obviously, distributions should build against Farsight.
Keep in mind that by stuffing media inside the library will turn it a
lot more complicated to use, can't we fix stream-engine to work
properly on desktop too?
Well as long it is optional Im ok with it...
There is a good documentation about tapioca API here:
But it was designed to work with telepathy itself so it is more
useful for mission control than application witch would probably
prefer talk directly to mission controls.
Luiz Augusto von Dentz
Engenheiro de Computação
More information about the Telepathy