Re-land first pass BackgroundTracingManager.

content/public/browser/background_tracing_preemptive_config.h

Index: content/public/browser/background_tracing_preemptive_config.h
diff --git a/content/public/browser/background_tracing_preemptive_config.h b/content/public/browser/background_tracing_preemptive_config.h
new file mode 100644
index 0000000000000000000000000000000000000000..ecf11636d853d1c1ff9cf8d77d264525d90c950e
--- /dev/null
+++ b/content/public/browser/background_tracing_preemptive_config.h
@@ -0,0 +1,47 @@
+// Copyright 2015 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 CONTENT_PUBLIC_BROWSER_BACKGROUND_PREEMPTIVE_TRACING_CONFIG_H_
+#define CONTENT_PUBLIC_BROWSER_BACKGROUND_PREEMPTIVE_TRACING_CONFIG_H_
+
+#include "content/public/browser/background_tracing_config.h"
+
+namespace content {
+
+// BackgroundTracingPreemptiveConfig holds trigger rules for use during
+// preemptive tracing. Tracing will be enabled immediately, and whenever
+// a trigger occurs, the trace will be finalized.
+struct CONTENT_EXPORT BackgroundTracingPreemptiveConfig
+    : public BackgroundTracingConfig {
+ public:
+  BackgroundTracingPreemptiveConfig();
+
+  enum RuleType {
+    MONITOR_AND_DUMP_WHEN_TRIGGER_NAMED,
+    MONITOR_AND_DUMP_WHEN_SPECIFIC_HISTOGRAM_AND_VALUE,
+    MONITOR_AND_DUMP_WHEN_BROWSER_STARTED,

[no sievers, 2015/05/14 21:25:17]

nit: STARTED -> STARTUP_COMPLETE?

[shatch, 2015/05/15 21:00:51]

Done.

+  };
+  struct HistogramTriggerInfo {
+    std::string histogram_name_to_trigger_on;
+    int histogram_bin_to_trigger_on;
+  };
+  struct NamedTriggerInfo {
+    std::string trigger_name;
+  };
+  struct MonitoringRule {
+    RuleType type;
+    HistogramTriggerInfo histogram_trigger_info;
+    NamedTriggerInfo named_trigger_info;

[no sievers, 2015/05/14 21:25:17]

Ok now here subclassing would make sense since you have the union of mutually
exclusive stuff.
Or what would also work is making a class and hiding the mutually-exclusive
fields as members, but having multiple factories for the corresponding type of
trigger.

Based on the other comments you could also make this part of the manager API
instead by having multiple interfaces there.

You should also consider for the future if the 'trace *after* an event happened'
would also eventually want to share internal events with the 'trace *before* an
event happens' category (such as the histogram based one) or vice versa (like
'navigation' you mentioned).

The way I look at this API is that you really just want to be able to say
'upload me a trace of a few seconds either before or after a list of certain
events' somehow. I'm afraid that going down this route is slightly complicated
to follow, and will become more complicated if you extend it later, and might
create ill-defined use cases.

[shatch, 2015/05/15 21:00:51]

Hrm, not quite following. Are you suggesting something along the lines of:

class BackgroundTracingManager {
  struct PreemptiveConfig {
    virtual void AddNamedTriggerRule(...);
    virtual void AddUMAHistogramTriggerRule(...);
  };
};


and then defining those in something like PreemptiveConfigImpl?

+  };
+
+  std::vector<MonitoringRule> configs;
+  CategoryPreset category_preset;
+
+ protected:
+  ~BackgroundTracingPreemptiveConfig() override;
+};
+
+}  // namespace content
+
+#endif  // CONTENT_PUBLIC_BROWSER_BACKGROUND_PREEMPTIVE_TRACING_CONFIG_H_