Le Fri, 10 Jul 2009 15:38:25 +0100, Will Thompson <[email protected]> a écrit :
> Alban Crequy wrote: > > Le Sat, 4 Jul 2009 02:01:32 +0100, > > Alban Crequy <[email protected]> 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 _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
