[Telepathy] Re: Spec changes involving FileTransfers and AppConnect channels

[Mads Chr. Olesen]

man, 09 10 2006 kl. 13:10 -0400, skrev Simon McVittie:
> Here at GNOME Summit there seems to be interest in doing crazy
> collaborative things over Telepathy :-) 
Crazy collaborative things has a lot of potential for niceness ;-)

> so I'm having a look through your
> changes and trying to get them reviewed and merged into Gabble Darcs.
Thank you very much :-) I have lacked the time and energy to push
further for a merge in the recent weeks.

> I haven't looked at your implementation in Gabble yet, so some of my
> criticisms here may be somewhat wrong, but after the long delay I
> thought I'd better get you *some* feedback as quickly as I can! As I've
> only just got involved in this, I'm missing a lot of context, so I'm
> going to have to read up on the JEPs and use cases too.
Please, if you have any questions I will be happy to answer them the
best I can!

> As you mentioned in your email back in August, the file transfer
> interface where the connection manager opens the file is less than ideal.
> Particularly, if you're using some sort of Telepathy equivalent of an
> IRC bouncer, it's possible that not all your Telepathy components are
> running on the same machine.
Hadn't really thought of running on separate computers - this will
surely have implications on the amount of traffic we can push back and
forth between client and conn. mgr.

> Mads Chr. Olesen wrote a patch which included:
> > +    def RecieveFile(self, filename):
> 
> ITYM "Receive".
Fine with me :-)

> > +        Returns how much of the file has been transferred, in bytes (0 - 2^64).
> 
> ITYM "0 - 2^64-1".
Yes, of course.

> > +class ChannelTypeAppConnect(Channel):
> > +    """
> > +    A channel for connecting an application at the local host, with an
> > +    application on a handle's remote host, through a socket connection.
> 
> ... "on a contact's (remote) host", ...
> 
> We should be careful to make it clear which type a handle is, since
> they're all just integers.
Noted.

> > +    @dbus.service.method(CHANNEL_TYPE_APP_CONNECT, in_signature='ss', out_signature='')
> > +    def Propose(self, app, socketaddr):
> > +        """
> > +        Sets what application we want to connect to, e.g. "Gobby",
> > +        and which UNIX socket address the local application is listening at, e.g.
> > +        "/tmp/gobby1". The channel will then start establishing the connection between
> > +        the two endpoints. When a connection is made to the local socket, communication
> > +        can start (the Connected signal will be emitted at the same time).
> 
> Some thoughts:
> 
> What's the scope of this extension? Do you intend to support arbitrary
> reliable streams, or just P2P D-Bus? 
Arbitrary reliable streams for "legacy" applications, with P2P D-Bus
being the "recommendation" for new applications.

> Or do we even want to support
> unreliable and/or packet-oriented connections, like UDP?
I don't think this is very useful - most applications that need an
unreliable service wants to do their own stuff anyway to have complete
control of what and how to retransmit, etc. It is of course possible,
there is at least support for it in the JEPs.

> If it's arbitrary reliable streams, in a way it'd be nice to be able to
> reuse some of the infrastructure used for streamed media, but specifying
> a reliable (TCP-like) stream.
I'm not that familiar with the media streams parts. Could you elaborate
on what could be reused?

> If the connection manager and the UI are running on different hosts the
> Unix socket won't actually work... if this is something we want to
> support at all.
See my previous note about bandwidth. 

> Rob Taylor points out that our design has always been that connection
> managers never open files, so we can run them "jailed" using SELinux.
> Using Unix domain sockets is less than ideal for this.
> 
> (It would be great if you could transfer a fd over D-Bus, but this is
> sadly not the case.)
Switching to something like a localhost TCP-socket will help us support
legacy applications more easily as well, something like running
"vncviewer localhost:7890" would be enough, otherwise we would need
something like "socat" to proxy from a TCP-socket to the UNIX-socket.

> If we *do* want to use Unix domain sockets (and for authentication
> purposes, they're a nice thing to be using), and we're restricting the
> communication protocol to be D-Bus, instead of a filename we
> should be using a (list of) D-Bus connection description(s) in
> the same format you'd find e.g. in the DBUS_SESSION_BUS_ADDRESS
> environment variable, such as
> "unix:abstract=/tmp/gobby.blahfoo;x-tcp:addr=127.0.0.1,port=12345".
Yes, this would be necessary. I avoided it for now, to have the client
not have to deal with unnecessary complexities.
I remember something about applying a hack on the fly to make the D-Bus
connection work between different hosts, if the uids differ. See
"gabble-app-connect-channel.c" line 539.

> > +        appname - the application's name
> > +            TODO: This should be a D-Bus object path, for D-Bus activation, etc., depending
> > +            on how mission control shapes out.
> 
> We could certainly do with some sort of namespacing for this, rather
> than just having it be some random string.
Yes. Either assume that every application has an unique D-Bus name, or
centrally administrate them. I vote for unique D-Bus names, it will also
allow us to activate applications in an easy way, if they are not
already running.

> > +    @dbus.service.method(CHANNEL_TYPE_APP_CONNECT, in_signature='', out_signature='s')
> > +    def Accept(self):
> > +        """
> > +        Accepts an incoming AppConnect request, telling the local application
> > +        which socket to connect to. The application should not begin connecting
> > +        to the local socket before the Connected signal has been emitted. 
> > +        Can only be called once, to minimize the risk of the channel being 
> > +        handled multiple times!
> > +
> > +        Returns:
> > +        the UNIX socket address of where the local application should connect,
> > +        to communicate over this AppConnect channel, e.g. "/tmp/appconnchannel1"
> > +
> > +        Possible Errors:
> > +        Disconnected, NotAvailable
> 
> Can we have some description of when each error is raised? I realise the
> rest of the spec isn't very good about this either. In particular, if
> you're saying that calling Accept twice is erroneous (which it is), it
> should be documented what gets raised in that case. When I get round to
> reading your implementation patches I'll reverse-engineer the error
> behaviour and write it up in the spec!
Hehe thank you. NotAvailable is called if accept is called twice, or if
propose has already been called on the channel.


If you have _any_ other questions, please don't hesitate to ask!

-- 
Mads Chr. Olesen <telepathy-ml at shiyee.dk>
shiyee.dk