[Bug 54875] make the default account backend store GVariants on disk

[bugzilla-daemon at freedesktop.org]

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

--- Comment #2 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
Next steps for this megabranch go something like this:

* Reimplement parameter type-coercion in terms of tp_variant_convert(),
  (extending that function if necessary), possibly falling back to how we
  do it now if tp_variant_convert() fails. tp_variant_convert is reasonably
  liberal (comparable to tp_asv_get_*), but doesn't do questionable things
  that we do in MC, like string <-> integer, or really stupid things
  that we only do because of our GKeyFile history, like
  string <-> string list.

* When we Get(Parameters), if the account has no untyped parameters,
  return the (typed) parameters with the types we know they have.

* Migration step: when an account's CM becomes ready, if it has any
  untyped parameters, and its backend supports typed parameters, find
  out their types from the CM and re-save them.

  (We might need to do this per backend rather than in general, or
  have a special case to not migrate secrets out of gnome-keyring
  (where they are always untyped) into plain text, or something.
  I don't think secrets other than 'password' actually exist in
  real CMs, though?)

* When we Get(Parameters), if the account has untyped parameters
  and the CM is not ready, make some sort of sensible assumption
  (for instance use the types from telepathy-spec and Haze, and
  assume that anything else is a string).

If a parameter is stored in type A but the CM expects it in type B, we should
try to convert it for the RequestConnection() call, but IMO we should *not*
convert the stored value unless/until the user actually calls UpdateParameters.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.