Bindings layer for declarative events API

chrome/browser/extensions/api/declarative/declarative_api.cc

Index: chrome/browser/extensions/api/declarative/declarative_api.cc
diff --git a/chrome/browser/extensions/api/declarative/declarative_api.cc b/chrome/browser/extensions/api/declarative/declarative_api.cc
new file mode 100644
index 0000000000000000000000000000000000000000..ca5fd83edad85faed77c6683dbe86fb7dd9f2d59
--- /dev/null
+++ b/chrome/browser/extensions/api/declarative/declarative_api.cc
@@ -0,0 +1,31 @@
+// 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.
+
+#include "chrome/browser/extensions/api/declarative/declarative_api.h"
+
+#include "base/values.h"
+
+namespace extensions {
+
+bool AddRulesFunction::RunImpl() {
+  // LOG(ERROR) << "AddRulesFunction called";
+
+  // We always return an empty list here. The binding of return values
+  // is handled in JavaScript by event.js.
+  result_.reset(new ListValue());

[not at google - send to devlin, 2012/02/01 07:23:12]

Why does the callback from addRules need to contain the rules it was passed,
anyway? I would have thought that it would be unusual for an extension to want
to know the rules, since it was the one which passed them in in the first place.
If the extension wants to know the rules, it should hold onto a reference to
them, as in,

var rules = [ ... ];
chrome.blah.someEvent.addRules(rules);

That would mean not needing to do new ListValue() here, and a simpler API
overall.

One reason I can see for passing the rules back through is if all state is lost,
for Matt's event pages. As I understand, "rules" would be lost if it's stored as
a local variable. In this case though, it would also be lost if kept as state of
the Event; so it should be the Browser which sends back the list of rules.

[battre, 2012/02/01 17:35:39]

The reasoning here was that rules are modified. The rules passed by the
extension don't need to contain identifiers and priorities. By the time of the
callback, these values are filled.

I am not completely convinced that the the strategy that the rules passed to
addRules() should require to have the same identity as the ones passed to the
callback. I think, the following would be sensible.

extension calls .addRules(rules)
--> C++ implementation validates rules and fills optional fields (such as rule
ids)
--> C++ passes new Dictionaries back to extension and calls the callback
function with this.

The reason I consider this better is
- With GetRules() we return new rules objects anyway
- The Extension background page can be killed and reopened with the new Event
pages mechanism, yet we need to be able to track which IDs have been used
already. We don't want to use a native function to generate unique rule IDs
because an extension might register 10.000 rules at a time and we don't want to
execute 10.000 IPC round trips for this.

+  return true;
+}
+
+bool RemoveRulesFunction::RunImpl() {
+  // LOG(ERROR) << "RemoveRulesFunction called";
+  return true;
+}
+
+bool GetRulesFunction::RunImpl() {
+  // LOG(ERROR) << "GetRulesFunction called";
+  result_.reset(new ListValue());
+  return true;
+}
+
+}  // namespace extensions