Bug 54872

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.

This branch introduces g_hash_table_add() and g_hash_table_contains() usage, so it will need a GLib 2.32 dependency. Imagine there was a patch here to add that, and I'll insert one when I merge :-)

this all looks reasonable to me, and i enjoyed a number of the comments.

Fixed in git for 5.15.0