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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
