[Telepathy] On removing/standardizing .profiles

[Simon McVittie]

On Tue, 13 Jul 2010 at 15:32:30 +0100, Vivek Dasmohapatra wrote:
> A proposed file format for the service profiles:
> 
> (0th draft, everythingis up for grabs at this point):
> 
> http://people.collabora.co.uk/~vivek/drafts/

If everything's up for grabs, can we get the XML to have a proper XMLNS? :-)
(or even two: one for the libaccounts wrapper, and one for everything inside
<manager>, which appears to be Telepathy-specific)

>     <!-- non-parameter settings are specified here - their types correspond 
>          to dbus types -->
>     <setting name="some-non-parameter-setting" type="i">-29</setting>

An example of this would be useful. Would this be used for a service type that
for some reason forced Enabled to be TRUE at all times, for instance?

Do these even need to have types? If they correspond to Telepathy Account
properties, can't the interpretation of the string be inferred from MC's own
knowledge, the same way it works for keyfile-based account storage?

>     <!-- now on to parameters: these are of types corrspoonding to dbus
>          types (only simple types so far)

We already have serializations for a subset of D-Bus types, which notably
also includes 'as' (array of strings).

Do these even need to have types? Can't the interpretation of the string be
inferred from MC's knowledge of the connection manager, the same way MC
currently interprets its keyfile-based account storage?

>     <!-- in this example we specify some additional statuses + labels
>          to be added to the stock list, and disable one   -->

It's never useful to add a status: if Gabble doesn't support 'online' as a
status, adding it to your XML won't help, since Gabble won't know how to map
it into the XMPP stream. If the service file lists a status that the CM
doesn't really support, that's a bug; Telepathy-literate components
should avoid displaying it, but a non-Telepathy-aware component
(libaccounts?) might not be able to avoid it.

However, it's potentially useful to re-label a status that the CM does support
(like the way the N900 re-labels the status that's internally called
'available' from "Available" to "Online" on Google Talk accounts[1]), to
change its icon, or to disable it (e.g. if you happen to know that a
particular provider can't support invisibility).

I think apply="modify" might be better phrased as allow-others="1" - the two
cases are "modify certain statuses but leave the rest intact", for services
with a few special cases, and "only allow a whitelist of statuses", for
services that support a small subset (Facebook) or control-freak UI
developers :-)

>       <presence id="away"      label="Away"
>                 message="1">Asleep at my desk</presence>

This isn't very illustrative. I can see a couple of possibilities for the
intention here:

* A service provider wants two statuses that, at the protocol level, are
  really the same, by (ab)using the user-defined message:

  <presence id="away" label="Asleep" message="Asleep on my desk"/>
  <presence id="away" label="Gone out" message="Gone to the pub"/>

  If this is what you want, I don't think it really makes sense for the label
  and the message to be different. I can see the appeal if you have a very
  small screen or something, but it makes the UI misleading (I selected
  a status that means one thing, and my contacts were shown something longer
  and more specific that might not have been what I meant).

  This is why we say in telepathy-spec that "Clients MUST NOT set
  a status whose string value they do not recognise, even if its presence type
  in Statuses matches what the user requested" - see the Status parameter of
  http://telepathy.freedesktop.org/spec/Connection_Interface_Simple_Presence.html#org.freedesktop.Telepathy.Connection.Interface.SimplePresence.SetPresence
  for full rationale.

* A service provider wants to force a particular message for a status, so you
  can't say 'away' at the protocol level unless it has message
  "Asleep on my desk". But why would you ever want to do that?

>     <!-- 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. For instance, some SIP providers
effectively have ImmutableStreams = TRUE, and we can't represent that in terms
of channel types.

It might be more useful to concentrate on concrete use-cases, which seem likely
to correspond to the sort of high-level feature represented by telepathy-qt4's
ensureTextChannel(), supportsAudioCalls(), etc. (which are thin wrappers around
a more general API).

I suspect most service quirks can be categorised as "this high-level feature
doesn't work even if the CM says it does" (e.g. we know that Google Talk can't
do geolocation), or possibly "this service only has these high-level features"
for things like Facebook Chat.

Regards,
    S

[1] I personally don't like that feature, but someone obviously decided that
  consistency between GTalk-on-N900 and GTalk-on-PC was more important than
  consistency between different profiles on the N900, and behind-the-scenes
  components like Telepathy should allow for any reasonable UI policy.