[Telepathy] Backward stream tube

[Will Thompson]

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.

> 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?

Regards,
-- 
Will

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20090710/c6d77718/attachment.pgp