[Telepathy] Review: telepathy-spec-stream

[Robert McQueen]

Dafydd Harries wrote:
> This seems a bit odd. Say we have TubeTypeTCPStream and TubeTypeUnixStream and
> TubeTypeAbstractUnixStream. Either:
> 
>  - The full type will be included in the stream offer, so that you're bound to
>    using the same type of socket as the remote end. This won't work if e.g.
>    you're using an abstract stream tube and you offer a tube to a client on a
>    Windows machine.

-1

>  - The offer will just say it's a stream tube, and the CM will need to pick
>    one of the socket types to use locally.

+1

> So I don't think the socket type should be dictated by the tube type.

Yeah, BSD sockets were right to seperate semantics (SOCK_STREAM) from
addressing (AF_UNIX), I think we should do the same.

> On the other hand: even if we do separate socket type from tube type, then if
> we want to give full flexibility to clients, we have to give them a way to
> choose which type of socket to use for a stream tube. We can't expect the CM
> to listen on a unix socket and a TCP socket for each tube.

Right, we need a way for clients to indicate what they want. On the
service side, maybe we can do TubeAddressType enum (so a uint) with
DBUS, UNIX, INET and INET6 values at the moment, and then have an ay for
the proto-specific thing? On the client side, not sure... suggestions?

Regards,
Rob