[Bug 54872] store account attributes, parameters in-memory as variants

[bugzilla-daemon at freedesktop.org]

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

--- Comment #1 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-09-13 15:50:41 UTC ---
Here's a bit more background on the data model in these branches.

Terminology I've been trying to stick to: each stored account has *attributes*
and *parameters*.

Attributes are mostly properties (like DisplayName), except for the ones that
aren't (like AvatarMime, avatar_token, AutomaticPresenceType). Mission Control
knows the desired type of each attribute, and only Mission Control can define
new attributes.

In the old accounts API, attributes were a map { attribute name => value
escaped as if for a GKeyFile } per account. In the new API, they are
conceptually a map { attribute name => GVariant value }.

In the old API, attributes could (in principle) be "secret", but this was never
used and I've abolished it. Attributes do have flags, which could be used to
reintroduce that sort of thing later. One thing I've thought about doing is a
CONFIG flag that means "this is configuration, store this in XDG_CONFIG_HOME
instead of XDG_DATA_HOME".

Parameters are the contents of the Parameters property. In the old API they
were effectively part of the attributes map, named "param-" + the parameter
name.

In the new API, it gets a little complicated. They are stored in two maps with
disjoint keys: one from name to GVariant value ("parameters"), and one from
name to keyfile-escaped string value ("untyped parameters"). In either case,
the names don't have the "param-" prefix any more; we know which maps to look
in from the API call being made.

When existing plugins load parameters from disk, if they know the type, they
put them in the typed map; otherwise, they put them in the untyped map by
calling older APIs. Entirely new plugins will presumably only store parameters
with known types, so they'll never need to interact with the untyped map at
all.

Parameters naturally migrate from the untyped map to the typed map whenever
they are changed with UpdateParameters(). In principle, we could also have a
migration step in which MC looks up connection manager details and uses those
to impose a type on previously-untyped parameters.

Parameters can still be "secret", but now it's part of a general-purpose flags
word. We could add a CONFIG flag here too, if we wanted to, for instance.

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