[Telepathy] On removing/standardizing .profiles

[Will Thompson]

drive-by:

On 13/07/10 16:20, Simon McVittie wrote:
> On Tue, 13 Jul 2010 at 15:32:30 +0100, Vivek Dasmohapatra wrote:
>>      <!-- if omitted, the standard manager channel classes are supported -->
>>      <!-- here we disable one channel type not normally available -->
>>      <!-- you could in principle _add_ channel types here, but since the
>>           CM wouldn't support them, that wouldn't mean much… -->
>>      <channel-types apply="modify">
>>        <!-- this service doesn't support streamed media (video, audio) at all -->
>>        <channel disable="1" type="StreamedMedia"/>
>>        <channel type="text">
>>          <!-- this service does support 1:1 and contact lists -->
>>          <handle-type>contact</handle-type>
>>          <handle-type>list</handle-type>
>>          <!-- this service does not support rooms/mucs/etc -->
>>          <handle-type disable="1">room</handle-type>
>>        </channel>
>>      </channel-types>
>
> If your aim is for this information to (be able to) replace what the CM says,
> this format is a regression: we're rapidly moving away from the idea that a
> channel type and a handle type is enough to identify any "class of channels",
> because it's just not true any more.

AFAICT there are two things to support here:

• Hide particular RCCs. For instance, the no-voip variants of the N900's 
Jabber profile could be represented by saying "hide everything with 
org.freedesktop.Telepathy.Channel.ChannelType: 
org.freedesktop.Telepathy.Channel.Type.Text", or by listing exactly the 
RCCs we want to hide. The latter is easier. As another example, we know 
that Facebook connections are not going to support File Transfer 
channels — even if other contacts are using real XMPP clients, their 
server doesn't let <iq/> stanzas through in general. (As an aside, the 
type of a channel is a fully-namespaced interface name, not "text".)
• Tweak RCCs. So the SIP case Simon gives: SM channels will have 
ImmutableStreams: True.

The format should be based on a list of serialized 
Requestable_Channel_Classes (which are (a{sv}as)), not by some custom 
hierarchical structure.
-- 
Will