[Telepathy] Telepathy specification meeting, 2009-05-13

[Will Thompson]

Hi,

As some might be aware, Collabora Cambridge-based Telepathy hackers
sporadically hold meetings in which we discuss potential improvements to
and issues with the specification. As a free and open project, we
welcome contributions to Telepathy from outside Collabora, striving to
keep Telepathy code review and technical discussions public (here, on
#telepathy on Freenode, and on the fd.o bugzilla).

Given this, our holding semi-secret, face-to-face internal discussions
to decide the direction of the spec. is unfortunate, but we believe it
to be necessary. We need to discuss clients' issues and requirements,
some or all of which cannot be made public; even when a meeting's agenda
can be public, holding meetings in person (rather on IRC, where others
could participate) allows for significantly higher-bandwidth discussion.

There is a danger that rationale for aspects of the specification will
remain only in the heads of those in these meetings, although we try to
add the rationale to the specification where possible. In addition,
we're going to start sending minutes of these meetings to this list.
Sorry if they're a bit skeletal; typing while debating is hard. :-)


Cast of Characters:

* Will "wjt" Thompson
* Simon "smcv" McVittie
* Sjoerd "sjoerd" Simons
* Guillaume "cassidy" Desmottes

New stream tube API
===================

http://git.collabora.co.uk/?p=user/cassidy/telepathy-spec;a=shortlog;h=refs/heads/stream-tube

* “The associated variant must contain a single byte with signature
  'y'”: perhaps “must contain a single byte (d-bus signature 'y')”?
* “connecting process if not the one expected.</p>”: typo: s/if/is

* On the side where a client application connects to the CM, the byte
  should just be a NUL; on the side where the CM connects to the client
  application, the CM generates a nonce to include in NewConnection and
  then ....
    - Rationale: when a client is connecting to the CM, there's no
      disambiguation needed; it's only needed when Gabble is connecting
      to the service being offered on a MUC tube.

Verdict: fix phrasing and merge.

Semantic of the Port access control when accepting a stream tube?
=================================================================

* When you call Accept() on the stream tube, you currently have to say
  from what port you're going to connect.
* This doesn't work if you want to connect multiple times, because you
  can't connect from the same port multiple times.
* Use case: sharing an HTTP server.
    - You can't tell ahead of time which port the browser will connect
      from anyway, so maybe the answer is “you can't do this with
      port-based access control”.
    - Or indeed, you can't do access control at all for legacy
      applications.
    - So maybe the answer is “cantfix”.
* Slightly orthogonally, Sjoerd thinks it's bong that you can connect
  multiple times to the same tube.
    - Gabble has to open one bytestream per connection; you can't
      meaningfully report errors with just one of the connections.
    - Currently, offering a stream tube has the semantics of listen().
    - Maybe we should reduce the similarity to TCP.

Verdict:

* If you're a legacy application, you can't use any access control
  mechanism other than localhost. Best practice: legacy applications
  being shared over tubes need in-band access control.
* If you're a flying car application, you should just pipeline. If we
  really want to allow flying cars to connect multiple times and use
  port-based access control we could add ReReConnect()/ConnectAgain().

Error reporting on Stream Tubes
===============================

How do we report errors if we can't actually set up a bytestream when
connecting to a stream tube service?

Suggestion: Gabble should only accept() when the bytestream has been
successfully initialized; then error reporting works just like any TCP
application.

We don't think this is possible: Gabble can't check (eg) the credentials
without accepting.  So we have to accept() and then close(). cf. browser
showing you an error vs.  showing you a blank page.

Open question.

CreateChannel might take a long time.
=====================================

* Making calls with InitialAudio/Video means that you wait for the disco
  reply before returning from CreateChannel.
* We should do this consistently if we do it at all, so that sending a
  file as soon as you sign on works.
* In the case of calls, nothing gets sent to the peer until we call
  StreamHandler.Ready() etc., so a channel being created and immediately
  closed after the UI has cancelled the ChannelRequest isn't so bad.
* But FT channels send the offer to the peer as soon as you create it.

Verdict seems to be: this is unfortunate but we can't avoid it. We
should make sure Mission Control and Decibel have a pretty big timeout
on calls to Requests.{Create,Ensure}Channel.

-- 
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/20090513/1115f04d/attachment.pgp