Add common code for extensions event filtering.

chrome/common/extensions/filtered_event_router.h

Index: chrome/common/extensions/filtered_event_router.h
diff --git a/chrome/common/extensions/filtered_event_router.h b/chrome/common/extensions/filtered_event_router.h
new file mode 100644
index 0000000000000000000000000000000000000000..e4a63176ceeb67b68b795886d6308e99aa3c295a
--- /dev/null
+++ b/chrome/common/extensions/filtered_event_router.h
@@ -0,0 +1,64 @@
+// 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_COMMON_EXTENSIONS_FILTERED_EVENT_ROUTER_H_
+#define CHROME_COMMON_EXTENSIONS_FILTERED_EVENT_ROUTER_H_
+#pragma once
+
+#include "base/memory/linked_ptr.h"
+#include "chrome/common/extensions/event_matcher.h"
+#include "chrome/common/extensions/event_filtering_info.h"
+#include "chrome/common/extensions/matcher/url_matcher.h"
+
+#include <map>
+#include <set>
+
+namespace extensions {
+
+// Matches incoming events against a collection of EventMatchers. Each added
+// EventMatcher is given an id which is returned by MatchEvent() when it is
+// passed a matching event.
+class FilteredEventRouter {

[battre, 2012/05/15 13:12:32]

Given that we are dealing with so many IDs, could you replace all ints with some
typedefs. This should simplify tracking which IDs are actually referenced.

E.g. in the condition_set_id_to_event_matcher_id_, we would use
URLMatcherConditionSet::ID as the first template parameter.

[Matt Perry, 2012/05/15 20:42:59]

How will this work in the multiprocess world of event pages? Will the event IDs
be synchronized between browser and extension processes? What happens when the
extension process is shut down and restarted?

[koz (OOO until 15th September), 2012/05/16 00:14:00]

Done.

[koz (OOO until 15th September), 2012/05/16 00:14:00]

The idea is that each process will maintain their own FilteredEventRouter which
will not synchronize event IDs. When an extension process is started and calls
to addListener() are made they will be sent to the browser in an IPC where it is
determined if that event/filter is already being listened to and does nothing if
it is.

Though thinking about it this deduplicating of event/filter pairs will have to
be done in linear time (on both the renderer and the browser). If we have users
specify an ID for their filtered event listeners then we can do it in constant
time. It would also mean we wouldn't need to have a FilteredEventRouter on the
renderer to do matching.

I think we talked about this before briefly and adding an ID parameter wasn't
considered as completely insane. What do you think? Does a linear time lookup on
addListener() warrant changing the interface?

[Matt Perry, 2012/05/16 00:37:32]

If I understand correctly, you're saying the events will have to be filtered
twice. i.e. once in the browser process to decide which processes to dispatch
to, then again in the renderer to decide which listeners to call. Maybe that's
not a big deal. I would expect process creation and IPC to take up the majority
of the time in event dispatch.

[koz (OOO until 15th September), 2012/05/16 01:01:21]

Actually I was more thinking about the cost of addListener() / removeListener(),
not dispatch. When the browser receives IPCs for adding an event/filter pair, it
will have to look through the filters already registered for that event and see
if this new one is a duplicate (otherwise we have that infinite listener problem
with event pages always adding fresh listeners).

We also need to perform that duplicate check on the renderer so that code like
this works:

chrome.filteredEvent.addListener(cb, filter);  // Sends IPC
chrome.filteredEvent.addListener(cb, filter);  // Doesn't send IPC
chrome.filteredEvent.removeListener(cb);  // Doesn't send IPC - shouldn't stop
browser from sending us 'filteredEvent's.

It'll only be linear in the number of listeners for a particular event on a
particular extension, so perhaps it wouldn't be that bad...

[Matt Perry, 2012/05/16 01:17:07]

What about:

chrome.filteredEvent.addListener(cb1, filter1);
chrome.filteredEvent.addListener(cb1, filter2);
chrome.filteredEvent.addListener(cb2, filter1);

Does the second or third call send an IPC? I don't think we need to optimize for
the case where both cb and filter are the same across 2 listeners.

+ public:
+  FilteredEventRouter();
+  ~FilteredEventRouter();
+
+  int AddEventMatcher(const std::string& event_name,

[battre, 2012/05/15 13:12:32]

Please document return values

[koz (OOO until 15th September), 2012/05/16 00:14:00]

Done.

+                      scoped_ptr<EventMatcher> matcher);
+  std::string RemoveEventMatcher(int id);
+
+  std::set<int> MatchEvent(const std::string& event_name,
+                           const EventFilteringInfo& event_info);
+
+  int GetMatcherCountForEvent(const std::string& event_name);
+
+ private:
+  typedef std::map<int, linked_ptr<EventMatcher> > EventMatcherMap;
+  typedef std::map<std::string, EventMatcherMap> EventMatcherMultiMap;
+
+  // Adds the list of filters to the URL matcher, having matches for those URLs
+  // map to |id|.
+  void AddURLConditionsToURLMatcher(int id, base::ListValue* url_filters);
+
+  URLMatcher url_matcher_;
+  EventMatcherMultiMap event_matchers_;
+
+  // The next id to assign to an EventMatcher.
+  int next_id_;
+
+  // The next id to assign to a condition set passed to URLMatcher.
+  int next_condition_set_id_;
+
+  // Maps condition set ids, which URLMatcher operates in, to event matcher
+  // ids, which the interface to this class operates in. As each EventFilter
+  // can specify many condition sets this is a many to one relationship.
+  std::map<int, int> condition_set_id_to_event_matcher_id_;
+
+  // Maps from event matcher ids to the name of the event they match on.
+  std::map<int, std::string> id_to_event_name_;

[battre, 2012/05/15 13:12:32]

DISALLOW_COPY_AND_ASSIGN

[battre, 2012/05/15 13:12:32]

this class has a lot of maps. I wonder whether we can simplify this. Can we get
rid of id_to_event_name_ if we change the signature of RemoveEventMatcher to
take both the event_name and the id?

[koz (OOO until 15th September), 2012/05/16 00:14:00]

Done.

[koz (OOO until 15th September), 2012/05/16 00:14:00]

We could, but wouldn't that just make the callers have to do more work by
remembering the id and the name?

+};
+
+}  // namespace extensions
+
+#endif  // CHROME_COMMON_EXTENSIONS_FILTERED_EVENT_ROUTER_H_