[Telepathy] Spec changes: tube API

[Dafydd Harries]

Ar 22/05/2007 am 10:33, ysgrifennodd Guillaume Desmottes:
> Hi,
> 
> 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).

To elaborate a bit on this:

We've been thinking that the way to make stream tubes work is to have the
Telepathy client offering a tube to listen on a socket and tell the connection
manager its address. The connection manager can then forward incoming
connections to the tube to the listening socket. This works a lot like ssh -R.
On the end that's connecting to the tube, the connection manager listens on a
local connection and tells the Telepathy client the address which then
connects to it. This is more like ssh -L.

 .---------.
 |TP client|--[listening socket] B
 '---------'         ^
     C               |
                .----------.
                |Connection|
                | Manager  | A
                '----------'
                     |
                   _____
                __/     \___
            ___/            \
           /                 \____
          |                       \
          \__                     /
             \    Internets      /
             /                   \
            /                     \
           |             ___      /
           \____/\      /   \____/
                  \____/
                     ^
                     |
                .----------.
                |Connection|
             F  | Manager  |-[listening socket] E
                '----------'        ^
                                    |
                               .---------.
                               |TP client| D
                               '---------'

The problem we're trying to solve is how to tell connection manager A the
address of listening socket B, and how to tell TP client D the address of
listening socket E.

The obvious way to do this without changing the API is for C to put the
B's address into its tube offer, and for A to strip this magic parameter out
before sending it over the internets. F would then put E's address into the
offer for the benefit of D.

Doing things this way means making some kind of distinction between parameters
meant for the connection manager and parameters meant for remote clients.

> 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).

What's the signature of added/removed?

-- 
Dafydd