[Telepathy] Spec changes: tube API

Guillaume Desmottes guillaume.desmottes at collabora.co.uk
Tue May 22 01:33:26 PDT 2007


I discussed yesterday with Simon and Rob about tubes API. I'd need a
easy way to define tube type specific properties when we create
(OfferTube) a new stream tube and current API doesn't allow us to do
that (we could use the parameters dictionary but that would be crack as
it's supposed to be used by client only).

Simon suggested the following changes:

OfferTube(u: type, a{sv}: type_params, a{sv}: client_params) -> u

The old "parameters" becomes client_params and each tube type can define
its own parameters in the type_params dict.
The current "service" argument can become type_params['service'].

With this solution we'll avoid to mess our API with tube specific
methods and signals using only a TypeParamsChanged signal and a
GetTypeParams method.
For example, GetDBusNames(tube) is replaced by GetTypeParams(tube,
'dbus-names') and DBusNamesChanged (tube, added, removed) is replaced by
TypeParamsChanged (tube, 'dbus-names', added, removed).

IMHO this API is saner and more flexible than our current one so I'd
vote for it.
I'm not sure if type params should be indexed using string keys or using
enums though.

About API breakage, tubes is currently considered as a unstable API in
telepathy-glib and AFAIK OLPC's connect activity is currently the only
application using it so I would not be a big issue to modify it.

Thoughts and comments welcome.


More information about the Telepathy mailing list