Hi Simon, On 10/16/07, Simon McVittie <[EMAIL PROTECTED]> 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 _______________________________________________ Telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
