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