[Bug 71093] New: finish making parameters fully typed

[bugzilla-daemon at freedesktop.org]

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

          Priority: medium
            Bug ID: 71093
          Assignee: telepathy-bugs at lists.freedesktop.org
           Summary: finish making parameters fully typed
        QA Contact: telepathy-bugs at lists.freedesktop.org
          Severity: enhancement
    Classification: Unclassified
                OS: All
          Reporter: simon.mcvittie at collabora.co.uk
          Hardware: Other
            Status: NEW
           Version: git master
         Component: mission-control
        Depends on: 54875
           Product: Telepathy

Quite a long time ago now, Will wrote:

    /* FIXME: this is ridiculous. MC stores the parameters for the account, so
     * it should be able to expose them on D-Bus even if the CM is uninstalled.
     * It shouldn't need to iterate across the parameters supported by the CM.
     * But it does, because MC doesn't store the types of parameters. So it
     * needs the CM (or .manager file) to be around to tell it whether "true"
     * is a string or a boolean…

Here is approximately what's left to fix that:

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

* 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.
You are the assignee for the bug.