Refactored SettingsFrontend and forwarding of calls to the backends.

chrome/browser/extensions/settings/settings_namespace_frontend.h

+// Copyright (c) 2012 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.
+
+#ifndef CHROME_BROWSER_EXTENSIONS_SETTINGS_SETTINGS_NAMESPACE_FRONTEND_H_
+#define CHROME_BROWSER_EXTENSIONS_SETTINGS_SETTINGS_NAMESPACE_FRONTEND_H_
+
+#include <string>
+
+#include "base/callback.h"
+
+class ValueStore;
+
+namespace extensions {
+
+class Extension;
+
+// Each namespace of the storage API implements this interface. It is mainly
+// used to look up the appropriate ValueStore for a given extension, and to
+// execute operations on that store.
+class SettingsNamespaceFrontend {

[not at google - send to devlin, 2012/07/18 07:46:18]

Name is rather indistinguishable from SettingsFrontend, also, especially vague.

So I guess this class is responsible for returning ValueStore instances on the
correct thread, and likewise deleting them on the right thread. And making sure
that only one is active per extension. How about... ValueStoreCache?

[Joao da Silva, 2012/07/18 21:40:25]

It's hard to name this one :-) That's a much better name, done.

+ public:
+  typedef base::Callback<void(ValueStore*)> StorageCallback;
+
+  virtual ~SettingsNamespaceFrontend();
+
+  // The frontend should invoke |callback| with the appropriate ValueStore for
+  // the given |extension|. If the extension is not found, the |callback|
+  // should be invoked with a NULL ValueStore.
+  virtual void RunWithStorage(const Extension* extension,
+                              const StorageCallback& callback) = 0;
+

[not at google - send to devlin, 2012/07/18 07:46:18]

If you add GetNaturalThread or whatever, a contract of this could be that it's
called on the correct thread (SettingsFrontend can easily arrange that).

Then this method could be synchronous i.e. just return the StorageCallback
rather than calling back with it. That would cut out a lot of the boilerplate in
SettingsStorageFrontend.

[Joao da Silva, 2012/07/18 21:40:25]

Done. The contract for this interface is now that it is created from UI, but
from then on lives on its preferred thread and all methods are invoked there
(except GetTaskRunner). In particular, the dtor is also executed on the
preferred thread.

+  // Requests the frontend to delete any storage used by |extension_id|.
+  virtual void DeleteStorageSoon(const std::string& extension_id) = 0;
+
+};
+
+}  // namespace extensions
+
+#endif  // CHROME_BROWSER_EXTENSIONS_SETTINGS_SETTINGS_NAMESPACE_FRONTEND_H_