# Service Profiles ## Synopsis Service Profiles are intended to describe variants of the basic protocols supported by telepathy CMs (Connection Managers): An example of this would be Google Talk vs Facebook chat vs Jabber/XMPP - Google Talk is a specific case of XMPP with well-known capabilities, quirks and settings, and Facebook chat is a subset of the standard XMPP offering. Since there is a lot of common content/use overlap between Telepathy profiles and libaccounts services, the intention here is to describe a single file format that can and will be shared by both. A service is uniquely identified by its name: When there is more than one possible choice of CM for a protocol, the preferred CM on any given platform is allowed to name its service profile based on the name of the service alone, and any other CMs profiles that represent the service should be named by prepending the CM name to the service name, separated by a dash '-'. --- ## Details ### XMLNS Namespace The XMLNS for service profiles is [[http://telepathy.freedesktop.org/wiki/service-profile-v1|http://telepathy.freedesktop.org/wiki/service-profile-v1]] A parser/reader/user of a service profile is expected to ignore (for telepathy purposes) any attributes or tags not in this namespace - other users of the file (such as libaccounts) which have their own information storage requirements should use a different namespace for any tags or attributes they add to the service profile file. A service profile is expected to provide the following information: ### service [[!format txt """ """]] #### id **mandatory** The unique name of the service. The preferred CM on a given platform is allowed to have a profile identified by service alone (eg "google-talk"). Any other CMs on the platform should be named - Examples: google-talk, haze-google-talk #### type **mandatory** The type of the service: In general, services of interest to both libaccounts and telepathy should be of type 'IM': Other service types exist but are unlikely to affect telepathy in any way #### manager **mandatory** The name of the CM (connection manager) Examples: gabble, haze #### protocol **mandatory** The standard telepathy name for the protocol over which this service is provided. Examples: jabber #### provider **optional** The name of the vendor/organisation/provider who actually runs the service to which this profile applies. Examples: google, facebook #### icon **optional** The base of the icon name for this service (to be looked for in the standard locations for icons used by the rest of the framework). Not explected to include either the type extension or the XxY size information, as these are considered to be entirely the domain of the UI. Examples: gtalk-icon, fb-icon ### name **mandatory** Human-readable name (possibly including required branding and so forth) for the service in question [[!format txt """ Google``Talk™ """]] ### parameters **optional** The CM parameters which describe the service: These can be mandatory, in which case the user shold not be allowed to alter them by the UI, as they define the service (google talk accounts _must_ connect to the actual google server, for example) or optional, in which case they merely specify defaults ehich may differ from the CM's defaults. These parameters are typed (with dbus types), so that libaccounts and telepathy can share the information. It is considered an error for the type of a parameter to differ from the type specified by the CM, although parsers are not required to enforce this (as they may be used in a context where the CM is unavailable and cannot be queried) Examples: * server, port, old-ssl (facebook, mandatory) * fallback-conference-server (google, optional) [[!format txt """ talk.google.com 5223 1 conference.jabber.org """]] The parameter tag has the following defined attributes: * name * string: The CM's name for this is (necessarily) canonical * type * string: (generally one character): the DBus type of the parameter * label * string: the human-readable label (if any) for the parameter * mandatory * boolean: (0 or 1, default 0): whether the value is fixed for this particular service ### presences **optional** A service can support a subset of the presences supported by a given protocol, and/or have service specific names for the standard presences. A specified presence in this section is considered to override any properties (label, icon, [default] extended message) of the standard entry for said presence in the CM. A presence may also be disabled, in which case the UI should not offer it as a choice to the user at all, as the service is not considered to support it. Examples: [[!format txt """ """]] The presences tag has the following attributes: * allow-others * boolean (0 or 1, default 0): whether the any standard CM presences not mentioned here are still supported The presence tag supports the following attributes: * id * string: the telepathy presence id string * label * string: the label for this presence, if it differs from the CM default * icon * string: the service specific icon for this presence, if any * message * boolean: (0 or 1, default 0): if true, a user-defined text message can be attached to this presence * disabled * boolean (0 or 1, default 0): if true, this presence is not supported ### unsuported channel classes **optional** Some services do not support the full range of channels that the protocol & CM are (in general) capable of: This item lists those channel classes which are not available on the service. Classes are defined (as in an ensure channel or create channel request) by a list of property/value pairs (an a{sv} in DBus terms): Example: [[!format txt """ 3 org.freedesktop.Telepathy.Channel.Type.Text """]] The property tag has the following attributes: * name * string: the telepathy DBus property of the channel * type * string (generally one character): the [DBus] type of the property ## Example [[!format txt """ Google``Talk™ talk.google.com 5223 1 conference.jabber.org profile.com 1111 3 org.freedesktop.Telepathy.Channel.Type.Text """]]