[Bug 24897] asses what to do about profiles

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=24897

Olli Salli <ollisal at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #8 from Olli Salli <ollisal at gmail.com> 2010-08-24 03:03:41 PDT ---
Had a private exchange with Alberto on this, continuing it here:

>> Are libaccounts clients actually interested in the manager and protocol,
>> or not? And no, we don't want them to be stored as settings and have to
>> be special-cased from other, actual settings (or rather parameters, see
>> below).
> 
> I'd say that generally they are not interested. The only client being
> very interested in them is MC, though. :-)

MC uses tp-glib, which will expose these fields, so I think that's sorted out -
or does MC definitely have to use libaccounts to parse the profile files? It
could just get the profile name from libaccounts and use tp-glib to parse it.

> 
>> I'm sorry, I'm not terribly familiar with whatever we use libaccounts
>> for, so please enlighten me.
> 
> libaccounts is being used by the accounts-ui to configure the account.
> So, all settings which a user is allowed to change should be accessible
> via the libaccounts API.
> It is also used by MC, to get the list of IM accounts, and their settings.
> 

Ok, so possibly we could add API to libaccounts to support the extra
semantics/API specific to IM accounts wherever needed?

>> Why did you ask us to draft a standard file format in the first place if
>> you aren't willing to make libaccounts support it?
> 
> 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.
> 

Surely the parser can map tp <parameter> elements to whatever libaccounts
<setting> elements are represented as in the API, be they inside a <group> with
a magic name or inside a <parameters> container? That is, there won't be
<parameter>s anywhere else anyway in the tp format so you can just get
<parameter> / <setting> nodes from any subtree starting from the root and use
them. (Or if you're using SAX just don't require them to be in any specific
container element when you encounter one).

>> The service-profile-v1 format is intended to be specific to representing
>> IM service profiles, we'd much rather not have any generic <group>
>> element type in there, as we just want a parameters container, and no
>> other "groups" of the sort.
> 
> 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.
> 
> The tree structure is rather powerful, although it might not be the most
> efficient, to cover most of the data description cases.

You shouldn't need to add any elements beyond the parameters and the name, most
likely.

> 
>> Also, having the per-parameter element be <parameter> is consistent of
>> how the rest of Telepathy calls account/connection *parameters*. Calling
>> them settings in profile files and parameters in manager files would be
>> confusing.
> 
> Well, but when talking about accounts we usually refer to them as
> "settings"; anyway, I'm not totally against changing this name, as long
> as we have only *one* element name for all single value elements in the
> XML file.
> 
> 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.
> Other things, such as the server address, are not common to all service
> types, but they might be used in all services of a specific service
> type, for instance IM. Since these things are different among different
> service types, we don't want to hardcode their names and semantics into
> libaccounts -- we just want to give the clients some way to retrieve
> them. The <group> and <setting> elements should do the trick well
> enough. If they don't, let's see why.

Fine, just treat <parameters> like you would treat <group name="parameters"> in
the parser then? Ditto for <parameter> vs <setting>? This way, clients using
actual Telepathy libraries (tp-glib, tp-qt4) will get them with the usual
semantics/naming they expect, and libaccounts clients will see them as
"settings" in a single group.

Frankly, this is what XML namespaces are for - and why we defined our namespace
to be service-profile-v1, not libaccounts-misc-whatever. You can easily support
both current libaccounts format and the standard TP profile format in your
parser if you take the namespace into account.

> 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) :-)
> 
>> The mandatory attribute doesn't mean the same thing in the profile draft
>> as it does in the .manager files.
>>
>> In .manager files, a parameter being mandatory means that SOME value
>> must be provided for the parameter always when creating an account /
>> requesting a connection.
>>
>> However, in profile files, a parameter being mandatory means that the
>> parameter must be set to *the specific value* specified by the element.
>> This is thus that eg. GTalk accounts will always connect to the actual
>> GTalk server (talk.google.com) instead of allowing the user to change
>> the parameter to some random jabber server. Note that in current gabble
>> .manager the server isn't even mandatory anymore, because we can do SRV
>> lookups based on the account parameter, but in a GTalk profile for
>> gabble it would be.
>>
>> I agree this is a bit confusing though. Maybe we should call mandatory
>> something different here - fixed-for-service? Just fixed?
> 
> 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.
> 

readonly sounds fine to me (read-only would be better naming though, or do we
need this to be compatible with libaccounts <setting> nodes?). The point of
having the attribute in the first place is to *NOT* have to hard-code all
profile-specific knowledge in the UIs. If we can represent this information in
a standard way in data/script files, there needs to be much less
profile/protocol-specific code in the UIs. These include desktop UIs like the
Empathy one and the aspiring KDE Telepathy ones too, mind you!. This is
especially important so that we can support installing new profiles without
code changes for them / compiled plugins, which is one design goal we had in
mind while designing the profile format.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.