[Telepathy] Telepathy specification meeting, 2009-05-25 (tubes, presence, streamed media and client capabilities)

[Will Thompson]

Hi,

Today, we discussed finally undrafting the new tubes APIs, a bug
relating to presence before you receive the roster, and (at length)
issues relating to advertising support for Google Video, leading to
considering changes to the (still DRAFT) ContactCapabilities API. We'd
welcome input on the final item, particularly if you have use-cases that
our current idea doesn't cover!

Dramatis Personæ:

* Guillaume "cassidy" Desmottes
* Sjoerd "sjoerd" Simons
* Will "wjt" Thompson
* Robert "Robot101" McQueen

and introducing:

* Arnaud "kutio" Maillet, as Someone Actually Using Tubes on the Desktop


== Should Channel.Type.DBusTube.Offer() and .Accept() have an
access_control argument? ==

* Current implementation is secretly Credentials (default D-Bus behaviour)
* By adding this parameter we could properly implement LocalHost and so
OLPC could stop patching Gabble
* Furthermore, Gabble's Windows port would be able to implement
LocalHost too
* We should probably add a SupportedAccessControl property as well then

Verdict:
* Yes.
* We don't need to add Socket_Address_Type because that's already
encoded in the D-Bus socket path.

Actions:
* Add the parameter to Offer and Accept
* Add the property
* Implement Localhost as well in Gabble and Salut
* Stop patching them in Sugar
* Also, merge the Sugar patch chmodding the stream tube socket if
Localhost is in use.

== Final review of Tube drafts ==

* "has been choosed" -> "has been chosen"
* references to enum types should be linkified
* Add a debug message to ConnectionClosed
* Define a tp:type for Connection_ID, for linkification and for better
generated code
* If feeling keen, document the errors the implementation raises in the
ConnectionClosed definition.
* Move the enums from Tubes to Tube, and mark the former as obsolete.
* We don't need to add error signals to the DBusTube interface (or
indeed the Tube interface) now. Since you can only connect to a DTube
once, we can just add a signal later if we need it without worrying
about tracking which connection broke.
* "To lower the barrier entry of new tube application" should be
"barrier to entry for new tube applications".

Verdict: fix and undraft.

== Unknown vs offline ==

Summary of the problem (which was reported at
[http://bugs.freedesktop.org/show_bug.cgi?id=20565 fd.o#20565]):

* Gabble is currently buggy, and does not delay GetPresences() till the
roster arrives to find out if a contact should be exposed as 'offline'
or 'unknown'.
* Independently, if you get a contact's presence with
GetContactAttributes() before the roster arrives, Gabble will say it's
'unknown', and then you won't get a PresencesChanged signal when the
roster arrives, even though repeating the GetContactAttributes() call
would yield a different result. So, TpContact gets out of sync.

Proposed solutions:

# Delay moving to state Connected until the roster arrives.
# Emit PresencesChanged for the entire roster when it arrives, and fix
GetPresences().

The former has the advantage that you don't get a giant PresencesChanged
flood for your entire roster when it arrives. But Rob pointed out that
the flood of updates is only a problem for applications which are
interested in presence for IDs they already know about before the roster
arrives, which implies that they keep a persistent cache of the roster.
So, they can just default the cached roster to all being offline until
proven otherwise, and not do anything in response to being told that
those contacts have moved from 'unknown' to 'offline'.

Verdict: emit PresencesChanged for everyone whose presence hasn't
already arrived when the roster arrives, and fix GetPresences() in
Gabble to be spec compliant.

Side point: the semantics of GetPresences() don't make sense for Salut,
in a sense, because 'subscribe' is defined to be the set of people for
whom you can receive presence there. Perhaps there should be a
representation of the set of contacts for whom you can expect presence
(which on Salut is what is currently 'subscribe', and in Gabble is the
union of subscribe, people who've sent directed presence, fellow MUC
participants, and possibly others).

== Streamed Media subtleties with respect to Google Video and MSN ==

Summary of the problems:

# The Google Video (and MSN; implied hereafter) client only supports a
fixed set of codecs. We should not advertise that we are capable of
video calling unless we actually support H264. So, we need a way to
communicate that a client supports H264 to the connection manager, so
that it can advertise our capabilities correctly.
# Once you start a Google Video call, you can't add or remove streams.
If you start with just audio, you're stuck with it, so if you want video
you have to ask for it from the start.

The second problem is easy: we define a new property,
StreamedMedia.Immutable, which is true on Google Video channels and in
the RequestableChannelClasses. The UI can use this to determine whether
it needs to offer separate "audio call" and "video call" options, or
just offer a "call" option and allow you to add video later.

The first problem is the big one.

The first suggestion was a StreamedMedia.SupportedCodecs
pseudo-property, whose value is a list of codecs. Clients then include
this in a HandlerChannelFilter. Unfortunately, it would have to be in an
extra channel class paralleling the real filter, and not actually appear
on the channel. If it were in all the filters and on the channel, then
if the CM emits the codecs in a different order, or has extra ones in
there because the peer making the incoming call supports them, MC won't
find any matching handlers, and will close the channel rather than
dispatching it. This is the same as the problem we had with representing
support for audio and video: rather than defining InitialStreams, a
property holding a list of stream types, we have separate InitialAudio
and InitialVideo properties.

After some toing and froing, we decided that the real issue is that
HandlerChannelFilter is overloaded both to match channels during
dispatch, and to be passed to SetSelfCapabilities on the connection
manager. We wanted to avoid Mission Control having to know stuff about
all the different channel types in order to pass capabilities down to
the CM differently for each one, which is a worthy goal.

We observed that the similarity between RequestableChannelClasses,
ContactCapabilities for others, and filters as used during dispatch is
good; it's the other direction that we have problems with. So, we
discussed clients having extra properties representing these kinds of
capabilities, rather than shoehorning pseudo-properties into the
filters. Suggested API:

* Define Client.Interface.StreamedMedia with SupportedCodecs,
SupportedStreamTypes, etc. properties; and similar interfaces, as
needed, for other channel types/interfaces.
* Mission Control calls GetAll on all interfaces on a client, and passes
an <tt>aa{sv}</tt> to SetSelfCapabilities, which it builds following
this pseudocode:

  caps = []
  for client in clients:
    props = {}
    for interface in client.interfaces:
      for key, val in client.GetAll(interface):
        props[interface ++ "." ++ key] = val
    caps.append(props)

* The CM figures out what to advertise based on this.
* This has the side-effect of allowing the CM to easily distinguish (a
client that supports H264, but not audio + a client that supports video
but not H264) from a client that supports audio and H264, so that in the
former case it doesn't advertise Google Video support.
* Will, while writing up these minutes, realised that
SetSelfCapabilities should actually accept an <tt>a(aa{sv}a{sv})</tt> —
a list of (HandlerChannelFilter, client properties) — so that for
properties which ''do'' make sense both in the filter and on the
channels (such as StreamTube.Service) we don't have to define
corresponding Client properties.

This way, we don't force things into the filters that don't really
belong there.

Verdict: we need to think about this some more before we commit
ourselves to the ContactCapabilities API. Adding these interface to the
Clients, however, doesn't break their APIs.

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/20090525/658edc72/attachment.pgp