[Telepathy] Backward stream tube

[Alban Crequy]

Le Fri, 10 Jul 2009 15:38:25 +0100,
Will Thompson <will.thompson at collabora.co.uk> a écrit :

> Alban Crequy wrote:
> > Le Sat, 4 Jul 2009 02:01:32 +0100,
> > Alban Crequy <alban.crequy at collabora.co.uk> a écrit :
> > 
> >> So we discussed how to design and implement this feature in the
> >> Channel.Type.StreamTube interface.
> > 
> > There are other issues if we reuse the existing interface
> > Channel.Type.StreamTube for backward stream tubes: the 2 methods
> > Offer's and Accept's prototype assume that the direction of the
> > tube is not backward:
> > 
> > 1. Called by the initiator:
> > Offer ( u: address_type, v: address, u: access_control, a{sv}:
> > parameters ) → nothing
> > 
> > 2. Called by the recipient:
> > Accept ( u: address_type, u: access_control, v:
> > access_control_param ) → v
> > 
> > With backward stream tube, the semantic would be different, for
> > example: 1. Called by the initiator:
> > Request ( u: address_type, u: access_control, a{sv}: parameters ) →
> > v
> > 
> > 2. Called by the recipient:
> > Offer ( u: address_type, v: address, u: access_control, a{sv}:
> > parameters ) → nothing
> > 
> > The field "v: address" is not at the same place.
> 
> I think this is okay. Suppose Alice wants Bob to share his VNC server
> with her:
> 
> * Alice calls CreateChannel({TargetID: Bob, ChannelType: StreamTube,
> Service: vnc, Reverse: True})
> * Gabble sends a message to Bob immediately
> * Bob's Vino handles the channel; "do you want to share your desktop
> with Alice?"
> * Bob clicks yes; his Vino calls Offer( ... ), including the address
> of the VNC server's socket.
> * Alice can now call Accept() n times to make n connections to the VNC
> server, and gets a socket each time.
> 
> In this calling pattern, the address arguments are all in the places
> you need them to be.

It looks fine, except the "call Accept() n times": Accept() should be
called only one time. Accept() returns the socket the CM is listening
on, and the local application can connect 1 time (VNC tube use-case), or
several times (DAAP tube use-case) on the same socket. Reverse tube or
not reverse should not change anything here.

> > Wjt suggested that telepathy-gabble can send the backward stream
> > tube request on the XMPP level to the contact directly when the
> > channel is created. But how can we handle the 'parameters' argument
> > in this case? Guillaume suggested the 'parameters' argument can be
> > useful both on the initiator side and on the side which offer the
> > service. With normal stream tubes, it is the same side, so it is
> > set by the Offer() method. But with backward stream tube, we have
> > to decide which side set the parameters, or if both side can set
> > the parameters.
> 
> We could allow Parameters to be supplied with Alice's CreateChannel()
> call, as well as in Bob's Offer() call. What's the use case for having
> parameters in both directions, even though only one side can set them
> in the "forward" tubes case?

I actually don't mind about the Parameters argument, but I think
Guillaume has some use-cases.

Regards,
Alban