[Telepathy] Backward stream tube

[Alban Crequy]

Hi,

On the way to Gran Canaria, we discussed IRL how we can implement
backward stream tubes. Here is my notes before I forget.

Purpose: Connect to a contact's desktop with VNC instead of sharing my
desktop with VNC. It is not possible to do this with the current stream
tube interface org.freedesktop.Telepathy.Channel.Type.StreamTube
because the initiator of the tube must the one who is supposed to
listen on a socket (not to connect on a socket).

The current "share my desktop" feature works like this (with normal
stream tubes):

  Initiator <--(unix socket)-- Gabble
 VNC server                      ^
   (Vino)                        | Tube magic
                                 |
  Recipient --(unix socket)--> Gabble
 VNC client
  (Vinagre)

The non-existent "connect to contact's desktop" feature should work
like this (with backward stream tube):

  Initiator --(unix socket)--> Gabble
 VNC client                      | Backward tube magic
  (Vinagre)                      |
                                 v
  Recipient <--(unix socket)-- Gabble
  VNC server
   (Vino)

I first proposed to have a new channel type
org.freedesktop.Telepathy.Channel.Type.ReverseStreamTube.DRAFT
(".DRAFT" to be removed later). It has the advantage to be easier to
keep compatibility. The previous Channel.Type.StreamTube interface do
not need to be not changed. But Sjoerd and Will think it is bad to have
2 different interfaces for basically the same feature (stream tube).

So we discussed how to design and implement this feature in the
Channel.Type.StreamTube interface.

The first issue is, how can this channel be dispatched to the right
application (let's say Vino or Vinagre in the VNC example). If this VNC
channel is requested by the address book or by Soylent, it is
dispatched to either Vino or Vinagre, depending on the
org.freedesktop.Telepathy.Channel.Requested D-Bus property. If
Requested is TRUE, we are on the initiator side and it is dispatched to
Vino because Vino claims to support vnc stream tube with Requested set
to TRUE according to its org.freedesktop.Telepathy.Client.* interfaces.
If Requested is FALSE, we are on the recipient side and it is
dispatched to Vinagre for the same reason.

With the reverse tube case, using the Requested D-Bus property cannot
work anymore. We need a different property, let's say
Channel.Type.StreamTube(.FUTURE).Direction which can be either "normal"
or "backward".

The problem with this new Direction property is that the current
version of Vino and Vinagre does not handle it, so their
Telepathy.Client.* interfaces would keep pretend to support both normal
VNC stream tube and backward VNC stream tube. This does not really
break the API, but it can have weird behavior if a client try to
connect to a contact's desktop and the VNC client is started on the
contact's computer instead of the VNC server.

We argued that the Telepathy integration in Vino and Vinagre is still
young so we may better add this new Direction D-Bus property quickly
while nobody really use tubes on the desktop.

So the Vino VNC server should support (in the Telepathy.Client.*
interfaces):
- stream tube of type VNC with Direction="normal" direction and
  Requested=TRUE
- stream tube of type VNC with Direction="backward" direction and
  Requested=FALSE

And the Vinagre VNC client should support (in the Telepathy.Client.*
interfaces):
- stream tube of type VNC with Direction="normal" direction and
  Requested=FALSE
- stream tube of type VNC with Direction="backward" direction and
  Requested=TRUE

Compability with the deprecated interface Channel.Type.Tubes: the
backward stream tubes should just not appear in the old Tubes interface.

Backward stream tubes in a MUC: I don't see any real use case for that.
You may want to connect to a chatroom member's desktop, but that would
be a 1-1 stream tube connection. Maybe if you want to play chess with
any member of a chatroom, so you connect to the first member who
accepts the tube. It may be needed with a stream protocol where the
initiator of the game has to connect to other players. Do we need to
differentiate the capability to do tube on a chatrooom and to do tube
with a contact?

Implementation details for XMPP: the VNC stream tube feature is
advertised with XEP-0115 Entity Capabilities using this string:

http://telepathy.freedesktop.org/xmpp/tubes/stream/vnc

We can keep this string for the normal stream tubes, and add a new
capability for backward stream tubes like this:

http://telepathy.freedesktop.org/xmpp/tubes/backward-stream/vnc

Cheers,
Alban