Mojom interface for Preferences

services/preferences/public/interfaces/preferences.mojom

Index: services/preferences/public/interfaces/preferences.mojom
diff --git a/services/preferences/public/interfaces/preferences.mojom b/services/preferences/public/interfaces/preferences.mojom
new file mode 100644
index 0000000000000000000000000000000000000000..91546ea35c98dc6946e62da918758fd7731a892c
--- /dev/null
+++ b/services/preferences/public/interfaces/preferences.mojom
@@ -0,0 +1,29 @@
+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+module prefs.mojom;
+
+// A Preference could be one of several base types. PrefStore utilizes
+// base::Value to encompass these. TODO(jonross): create struct traits so that
+// we can pass base::Value via mojo.
+struct Preference {
+  enum PreferenceType { INT, STRING };
+
+  PreferenceType type;
+  uint32 integer_value_;
+  string? string_value_;
+};

[Elliot Glaysher, 2016/07/26 21:11:58]

If you're only supporting integers and strings here, how do you support
maps/arrays? If you aren't supporting maps/arrays, how are you dealing with
nested preferences, which are the vast majority of the preferences?

(Amazingly, none of the prefs read or written in
c/b/u/ash/chrome_launcher_prefs.cc are written like this. This interface is
probably Good Enough for ash, though it won't be good enough for most anything
else.)

Keys in the preference system, of the form <one>.<two>.<three> actually map to:

{
  "one": {
    "two": {
      "three": 0,
    }
  }
}

Asking the preference system for one.two.three returns 0, one.two returns {
"three": 0 } and so on.

Setting and returning dictionaries that contain multiple keys (or entire
subtrees!) is used all over the place; I just plugged a few random preferences
form my Preferences file into the code to check. ("default_search_provider" sets
whole hierarchies to the top level preference, "extensions.chrome_url_overrides"
isn't a full path, but one which gets set with a complex value.) I could see
this pattern continuing in a mojoified world: observe "default_search_provider"
to receive that entire preference tree, with child preferences. 

[jonross, 2016/07/26 21:37:35]

I started with int/string to cover the test case of the shelf.

What I would like to to is to build strut_traits for the various base::Value
subclasses. Which would allow for the passing of the more complicated
dictionaries of preferences.

+
+// Used to subscribe to preference changes within PreferenceManager. After
+// requesting to observe, the current values for all requested keys are sent.
+interface PreferenceObserver {
+  OnPreferencesChanged(map<string, Preference> preferences);
+};
+
+// Manages actual read/write of preference data. Accepts observers who subscribe
+// to preferences, notifying them of changes.
+interface PreferenceManager {
+  AddObserver(array<string> preferences, PreferenceObserver client);
+  SetPreferences(map<string, Preference> preferences);
+};