[Bug 24897] asses what to do about profiles

[bugzilla-daemon at freedesktop.org]

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

--- Comment #9 from Alberto Mardegan <mardy at users.sourceforge.net> 2010-08-24 04:38:36 PDT ---
(In reply to comment #8)
> 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.

Since libaccounts is parsing these files anyways, I'd rather have their content
exposed somehow in the libaccounts API. Currently libaccounts has an API to
retrieve the file contents (not the filename, though that could be added too),
but of course it would be better if we find a direct solution.

> > 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?

Indeed.

> >> 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).

This is indeed technically possible, but read below...

[...]
> > 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?

This was actually working but Mikhail didn't like it -- and I agreed; see
internal nokia bug 173355. Summing up, his remark was:

"This still uses the XML syntax so it could be parsed by an XML parser, but is
not a good practice for anything other that XML can help with, like document
validation or XSLT transformations."

> Ditto for <parameter> vs <setting>?

This is a slightly different thing. In libaccounts there is

<setting name="server" type="s">talk.google.com</setting>

and AFAIU you are not proposing to have

<server type="s">talk.google.com</server>

but just a renaming of the element:

<parameter name="server" type="s">talk.google.com</parameter>

Which would be perfectly fine, and we can even support "parameter" as alias for
"setting", it's just that I see it as just a cosmetic issue not worth a change.
You prefer talking about "account parameters", I prefer "account settings". Or
did I miss your point?

> 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.

Mmm... first of all, we don't have yet a concept of read-only setting in
libaccounts; it would be a new thing, so we can come up with anything we like.

But, as it comes to dynamically generated UIs for service settings, I'll run
the risk to violate some secret and describe how this is being done in the
Maemo Harmattan account-ui: although the UI is dynamically generated from the
.service files, its description is under a different XML element, mainly
because not all telepathy parameters should be exposed in the UI as account
settings, and not all account settings are telepathy parameters. Also, one UI
widget might cover two telepathy parameters (for instance server + port could
be one common widget). Cutting it short, in general there is no 1-1
correspondence, unless you want a really trivial (and ugly :-) ) UI.

So, we have something like that:

<ui>
  <layout type="flow">
    <widget type="text" label="Server:" mandatory="true"
key="parameters/server"/>
    <widget ... />
  </layout>
</ui>

And this allows us to have different layouts, and create more fancy widget in
the future. Recalling the example above, we might have a smarter UI parser
which could build widgets like this

<widget type="server" label="Proxy">
  <setting type="address" key="parameters/server"/>
  <setting type="port" key="parameters/port"/>
</widget>

That's actually why libaccounts allows the client to get the contents of the
file: not for parsing the settings, but for any other application specific
things that it doesn't recognize. Of course it would be better if it could
expose everything through its APIs, but that would also mean limiting the XML
structure.
I also thought that libaccounts-glib could expose the xmlTextReaderPtr it is
using internally, but in that way we wouldn't be free to move to some other XML
parser, and it might be a PITA to write bindings to other languages.

On the other hand, for things like UI descriptions, which are probably specific
to an application only (the accounts-ui), it might be better to keep those
things out of the .service file, and ship a different XML file, with a format
defined by the application, in another filesystem location which can be derived
from the service name. For instance, there could be

/usr/share/maemo-accounts-ui/<service name>.xml
/usr/share/empathy/services/<service name>.empathy
...

each file with the format defined by the application which is using them.
The bad side of this is that the service provider needs to ship several files
instead of one only, but it's not a big deal.
The good sides:
1) most applications would be parsing less XML code (for instance, MC wouldn't
parse the empathy or maemo-accounts-ui files, since it doesn't need any
information contained in them)
2) ease of installation and upgrade: when someone comes up with the rocking KDE
accounts-ui, providers willing to support it will just have to have one small
package which ships this UI's specific file, without touching the existing
ones.

-- 
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.