[Telepathy] On removing/standardizing .profiles

[Vivek Dasmohapatra]

Continued discussion from out of band, adding here so it's on the
public list (where it should be, we got a bit careless, sorry):

> Depends what you mean by "support". There could be different levels of 
> support, the least one being "compatible": libaccounts successfully 
> loads the service file you define, and ignores all elements it doesn't 
> recognize.

That would be entirely fine, I believe that was the original goal:
We have a situation where we have a significant overlap of information
between MC, tp-qt4 and libaccounts-*, and the information has to be
canonical from MC's POV as it is the component stuck in the engine room
shovelling coal into the boiler...

So we are trying to define a mutually acceptable format that contains all 
this information [I believe we have, although I have no objection to 
updating it in line with mikhail's latest comments], but allowing extra 
information to be added (by the namespacing described in the spec)

> But I wouldn't like to modify libaccounts every time an element is added to any
> service file (you are defining the format for IM services, but there are many
> more -- sharing, e-mail, calendar, social networking...), so I'd rather
> libaccounts provide clients with a way to retrieve any information they want.

I don't think there's any problem with that here - MC et al will ignore
(by design) any tags not in their namespace, so libaccounts-* et al can
claim their own namespace, allowing them to co-exist.

> To clarify: there are a few basic properties that are more or less used in all
> services, whatever type they belong to. For instance, the "name", "icon",
> "enabled" properties are common to all services, whether they are IM, e-mail,
> sharing or what not. These deserve their own element name in the XML file, and
> must be available through libaccounts APIs.

I don't think the decision as to whether these are individual well known 
tags or well known attributes of the service tag will make a huge 
difference. Either way each item of info mentioned will have a well 
defined location, which is all we really care about.

> So, my initial call was to invite the Rtcom/Telepathy people to define a set of
> settings for the IM service type, not to redesign how libaccounts works
> (although if there are good reasons to do so, that can be done too) :-)

Well, we have a couple of extra requirements, like specifying the kinds
of channels a service can handle (some service may not support some types
of channels that are otherwise supported by the CM, for example).

What we've aimed for is representing this information in a way which 
matches the way it is used over DBus and in telepathy in general, since
most things that use the info will already be (or will _have_ to be)
able to deal with the info in that form, being telepathy components
or things related to them.

> It could be a 'readonly="true"' attribute on the setting, meaning that this
> setting cannot be overriden by setting the same key on the accounts DB: the XML
> file will always have precedence over the account DB for this key. But on the
> other hand, do we need it? The users are not editing the accounts DB by hand,
> they only do via a UI which should know what settings to show.

The point of the service file is to define a service for any component
(MC, a UI, libaccounts) that needs this information: A service profile
that _doesn't_ define the service-specific settings wouldn't really be
filling this function for us.

To sum up - we've got a big overlap of the information required for 
service profiles between various components - this [proposed] file
format is an attempt to provide said information to all interested
parties in a way that fits well with telepathy/dbus use, while allowing
each component its own namespaced sandbox to put in info that is
of interest only to it - hopefully, by doing this, we can avoid
duplicating the information and all the problems that arise when
multiple service definitions get out of sync.

So the plan is: - merge Mikhail's suggested changes
                 - ship it

This might mean some more (but hopefully not a lot) of work for components 
that currently already have a representation of [some] of this 
information, but I think it will pay for itself in terms of problems and 
bugs avoided.