[Telepathy] Spec changes: tube API

[Mads Chr. Olesen]

tir, 22 05 2007 kl. 13:29 +0100, skrev Dafydd Harries:
> 
>  .---------.
>  |TP client|--[listening socket] B
>  '---------'         ^
>      C               |
>                 .----------.
>                 |Connection|
>                 | Manager  | A
>                 '----------'
>                      |
>                    _____
>                 __/     \___
>             ___/            \
>            /                 \____
>           |                       \
>           \__                     /
>              \    Internets      /
>              /                   \
>             /                     \
>            |             ___      /
>            \____/\      /   \____/
>                   \____/
>                      ^
>                      |
>                 .----------.
>                 |Connection|
>              F  | Manager  |-[listening socket] E
>                 '----------'        ^
>                                     |
>                                .---------.
>                                |TP client| D
>                                '---------'
> 
That ASCII-art just cracked me up :-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.
The world has enough magic as is...

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

Instead of changing the current method to create all kinds of tubes,
with all possible parameters, what about making separate methods for
each kind of tube?
OfferDTube(s: service, a{sv}: parameters)
OfferStreamTube(s: socket_addr, a{sv}: parameters)
OfferDataGramTube(...)

I can only think of a limited number of different tube-types, so having
it abstracted in an enum actually doesn't make that much sense to me.

-- 
Mads Chr. Olesen <shiyee at shiyee.dk>
shiyee.dk