[Telepathy] Proposed Telepathy client GLib API

[Luiz Augusto von Dentz]

Hi Simon,

On 10/16/07, Simon McVittie <simon.mcvittie at collabora.co.uk> wrote:
> 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

I would add:
 * Thread safe or multi-threaded.

> Non-goals:
> * 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
>   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
>
> * 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
would prefer
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:
http://tapioca-voip.sourceforge.net/docs/api/0.4.4/tapioca-api.html
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