[Telepathy] On removing/standardizing .profiles

[Andre Moreira Magalhaes]

Hi all,

So after working on implementing support for profiles in tp-qt4 I came
up with some issues and ideas I would like to discuss.

The proposal here is based on the work done by Vivek found in
http://people.collabora.co.uk/~vivek/drafts/

You can find the modified XMLs in
http://people.collabora.co.uk/~andrunko/drafts/

Note that some things here are already found in Vivek's proposal, or
already proposed in this thread, and I am just being pedantic.

So what needs to be defined and how I think it should look like:

- Where to install profiles:

  To look up a profile, clients should search the data directories
specified by the freedesktop.org XDG Base Directory Specification
($XDG_DATA_HOME, defaulting to $HOME/.local/share if unset, followed by
colon-separated paths from $XDG_DATA_DIRS, defaulting
to /usr/local/share:/usr/share if unset) for the files named
telepathy/profiles/$cmname.profile or
telepathy/profiles/$cmname-$servicename.profile that can be read without
error.
  This file is a XML file that follows an specific format.

  Once one profile is found for a given service, all other profiles
defining the same service using the same CM and protocol should be
ignored.

  All CMs should ideally install a profile named $cmname.profile that
will contains the default profiles for that given CM. We should also
allow installation of new profiles for a given CM for custom services.
These profiles will be named $cmname-$servicename.profile and should be
preferred over the profile for the service defined in the main CM
profile in case it is already defined there. Custom .profile files
should only contain one "service" element.

  This is very similar to what we find today for manager files with the
addition to support installation of new profiles without changing the
default profile, provided by the CM.

- i18n:
  
  We should support i18n of fields such as supported presences and
parameters defined in profiles. As CM parameters names are not defined
in the spec we should be able to add proper translations for parameters.
Ideally presence types should also be translated, but this may not be
needed as presences are defined in the spec, so UIs can easily add
translations for all supported presence types. The idea here is to add a
"label" child element that contains a "lang" attribute for all possible
fields that can be translated. For example:

    <parameter id="server">
      <label lang="en-us">Server</server>
      <label lang="pt-br">Servidor</server>
    </parameter>

- Parameters:

  Profiles must be able to define a value for a parameter and whether
this parameter is mandatory or should be disabled for a given service. 
  The "parameter" element should support a boolean attribute "mandatory"
for mandatory parameters and a attribute "value" to define the default
value. For example:

   <parameters>
    <parameter id="server" value="talk.google.com" mandatory="true">
      <label lang="en-us">Server</server>
      <label lang="pt-br">Servidor</server>
    </parameter>
    ...
   </parameters>

  Maybe we should add a boolean attribute "editable" to indicate whether
the parameter is editable for this service or must be the same indicated
by the "value" attribute.

- Presence:

  Some services do not support all presence types defined in the spec,
so we should indicate whether some presences are known to not be
supported.

  A boolean attribue "disabled" should be added to the "presence"
element if a given presence type is known to not be supported.

  Presences not defined by the spec should be ignored.

  i18n should follow the same idea used by parameters:

  Example:
   
    <presences>
     ...
     <presence id="away">
      <label lang="en-us">Away</away>
      <label lang="pt-br">Ausente</away>
     </presence>
     <presence id="hidden" disabled="true"/>
    </presences>

- Capabilities:

  The CM already provides all capabilities it may support, the idea here
is to be able to indicate that certain capabilities are not supported
for certain service. For example facebook service does not support MUC.

  To do this we should add a "supressed-requestable-channel-classes"
element that contains child elements "item" for all RCCs not supported.
The syntax of the "item" element value should be the same used to define
RCCs in manager files (See Protocol).

  Example:

  <suppressed-requestable-channel-classes>
   <item>
    org.freedesktop.Telepathy.Channel.ChannelType
s=org.freedesktop.Telepathy.Channel.Type.RoomList
    org.freedesktop.Telepathy.Channel.TargetHandleType u=2

allowed=org.freedesktop.Telepathy.Channel.TargetHandle;org.freedesktop.Telepathy.Channel.TargetID;
   </item>
  </suppressed-requestable-channel-classes>

  This indicates that this service do not support MUC by adding an item
element with the RCC to suppress.

Issues not covered:

- How to add translations for available presences and parameters without
replicating the same info for all services in a given CM.

  Possible solution:
  - Add global "parameters" and "presence" elements that will only
support the "lang" child element and the "id" attribute.

  Example:

  <services>

   <parameters>
    <parameter id="server">
     <label lang="en-us">Server</server>
     <label lang="pt-br">Servidor</server>
    </parameter>
    ...
   </parameters>

   <presences>
    <presence id="away">
     <label lang="en-us">Away</server>
     <label lang="pt-br">Ausente</server>
    </presence>
   <presences>

   <service>
    ...
   </service>

  </services>


tp-qt4 implementation:

You can find skeleton classes that I believe cover all above ideas in 
http://git.collabora.co.uk/?p=user/andrunko/telepathy-qt4.git;a=shortlog;h=refs/heads/profiles

The class Tp::Profile represents one single profile. The class
ProfileManager is used to retrieve all available profiles and should be
used to build account creation UIs.

We should also add method/property to Tp::Account that will return an
instance of a Tp::Profile object representing the account profile for
the account CM/service/protocol.

Also I believe a good addition for Tp::Account would be to add a
capabilities method/property (with the corresponding capabilitiesChanged
signal) that should return an instance of ConnectionCapabilities.
The returned capabilities should represent the intersection of the CM
capabilities defined in o.f.t.I.Protocol with the profile capabilities
if the account is offline and the connection capabilities when the
account is online.


Well that is basically it, sorry for the very long mail, but I believe I
covered all the ideas and issues I found and that were already discussed
here.

BR
Andrunko