Implementation of beginning of Declarative Web Request API backend

chrome/browser/extensions/api/declarative_webrequest/webrequest_rules_registry.h

Index: chrome/browser/extensions/api/declarative_webrequest/webrequest_rules_registry.h
diff --git a/chrome/browser/extensions/api/declarative_webrequest/webrequest_rules_registry.h b/chrome/browser/extensions/api/declarative_webrequest/webrequest_rules_registry.h
new file mode 100644
index 0000000000000000000000000000000000000000..7682df2942b0064a7cb761d4ccc727591ec85b6c
--- /dev/null
+++ b/chrome/browser/extensions/api/declarative_webrequest/webrequest_rules_registry.h
@@ -0,0 +1,99 @@
+// 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_API_DECLARATIVE_WEBREQUEST_WEBREQUEST_RULES_REGISTRY_H_
+#define CHROME_BROWSER_EXTENSIONS_API_DECLARATIVE_WEBREQUEST_WEBREQUEST_RULES_REGISTRY_H_
+#pragma once
+
+#include <vector>
+
+#include "base/memory/linked_ptr.h"
+#include "chrome/browser/extensions/api/declarative/rules_registry_with_cache.h"
+#include "chrome/browser/extensions/api/declarative/url_matcher.h"
+
+namespace net {
+class URLRequest;
+}
+
+namespace extensions {
+namespace declarative_webrequest{
+class WebRequestRule;

[Matt Perry, 2012/03/22 01:34:43]

nit: just move this into the namespace block below

[battre, 2012/03/26 18:35:51]

Done.

+}
+}
+
+namespace extensions {
+namespace declarative_webrequest{

[Matt Perry, 2012/03/22 01:34:43]

We shouldn't go overboard with namespaces. I think scoping all this stuff in the
extensions namespace should be good enough.

[battre, 2012/03/26 18:35:51]

Done.

+
+// The WebRequestRulesRegistry is responsible for managing
+// the internal representation of rules for the Declarative Web Request API.
+//
+// Here is the high level overview of this functionality:
+//
+// RulesRegistry::Rule consists of Conditions and Actions, these are
+// represented as a WebRequestRule with WebRequestConditions and
+// WebRequestRuleActions.
+//
+// WebRequestConditions represent JSON dictionaries as the following:
+// {
+//   'instanceType': 'URLMatcher',
+//   'host_suffix': 'example.com',
+//   'path_prefix': '/query',
+//   'schema': 'http'

[Matt Perry, 2012/03/22 23:07:25]

schema -> scheme

[battre, 2012/03/26 18:35:51]

Done.

+// }
+//
+// The evaluation of URL related condition attributes (http_suffix, path_prefix)

[Matt Perry, 2012/03/22 01:34:43]

host_suffix*

[battre, 2012/03/26 18:35:51]

Done.

+// is delegated to a URLMatcher, because this is capable of evaluating many
+// of such URL related condition attributes in parallel.
+//
+// For this, the URLRequestCondition has a URLMatcherConditionSet, which
+// represents the {'host_suffix': 'example.com', 'path_prefix': '/query'} part.
+// We will then ask the URLMatcher, whether a given URL
+// "http://www.example.com/query/" has any matches, and the URLMatcher
+// will respond with the URLMatcherConditionSet::ID. We can map this
+// to the WebRequestRule and check whether also the other conditions (in this
+// example 'schema': 'http') are fulfilled.

[Matt Perry, 2012/03/22 01:34:43]

I just started reviewing and don't have the full picture in my head, but this
seems weird. "schema" is a property of a URL - there's nothing specific to
WebRequest in there. Why not have URLMatcher/URLRequestCondition handle schemas
as well?

[battre, 2012/03/26 18:35:51]

I have changed the example to 'has_cookie': {'name': 'Pref'}.

Regarding the scheme, I would like to keep this as a condition attribute (i.e.
something that is checked after the string matcher informs us for the simple
reason that we can allow constructs like these 'scheme': ['http', 'https']

+class WebRequestRulesRegistry : public RulesRegistryWithCache {
+ public:
+  typedef std::string ExtensionId;
+  typedef std::string RuleId;
+  typedef std::pair<ExtensionId, RuleId> GlobalRuleId;
+
+  WebRequestRulesRegistry();
+  ~WebRequestRulesRegistry();
+
+  // TODO(battre): This will become an implementation detail, because we need
+  // a way to also execute the actions of the rules.
+  std::set<GlobalRuleId> GetMatches(net::URLRequest* request);
+
+  // Implementation of RulesRegistryWithCache:
+  virtual std::string AddRulesImpl(
+      const std::string& extension_id,
+      const std::vector<linked_ptr<RulesRegistry::Rule> >& rules) OVERRIDE;
+  virtual std::string RemoveRulesImpl(
+      const std::string& extension_id,
+      const std::vector<std::string>& rule_identifiers) OVERRIDE;
+  virtual std::string RemoveAllRulesImpl(
+      const std::string& extension_id) OVERRIDE;
+  virtual content::BrowserThread::ID GetOwnerThread() const OVERRIDE;
+
+ private:
+  // Checking which rules match for a URLRequest is a two staged process.
+  // First we check all condition attributes regarding the URL. Each Rule is
+  // associated with URLMatcherConditionSets for these attributes. In case
+  // of a match, we also test the remaining condition attributes.
+  typedef std::map<URLMatcherConditionSet::ID, WebRequestRule*> RuleTriggers;
+  RuleTriggers rule_triggers_;
+
+  typedef std::map<GlobalRuleId, linked_ptr<WebRequestRule> > RulesMap;
+  RulesMap webrequest_rules_;
+
+  std::map<WebRequestRule*, GlobalRuleId> rule_ids_;

[Matt Perry, 2012/03/22 23:07:25]

You could avoid needing this by having RuleTriggers be a
std::map<URLMatcherConditionSet::ID, std::pair<GlobalRuleId, WebRequestRule*> >

[battre, 2012/03/26 18:35:51]

Done.

+
+  URLMatcher url_matcher_;
+};
+
+}  // namespace declarative_webrequest
+}  // namespace extensions
+
+#endif  // CHROME_BROWSER_EXTENSIONS_API_DECLARATIVE_WEBREQUEST_WEBREQUEST_RULES_REGISTRY_H_