[Telepathy] Review: telepathy-spec-stream
robert.mcqueen at collabora.co.uk
Tue Jun 5 06:30:28 PDT 2007
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.
> - 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.
> 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?
More information about the Telepathy