Re-land first pass BackgroundTracingManager.

content/public/browser/background_tracing_config.h

Index: content/public/browser/background_tracing_config.h
diff --git a/content/public/browser/background_tracing_config.h b/content/public/browser/background_tracing_config.h
new file mode 100644
index 0000000000000000000000000000000000000000..af97e26374cc9d075a6f7db4ff5ac6ea4e3ae14e
--- /dev/null
+++ b/content/public/browser/background_tracing_config.h
@@ -0,0 +1,46 @@
+// 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_TRACING_CONFIG_H_
+#define CONTENT_PUBLIC_BROWSER_BACKGROUND_TRACING_CONFIG_H_
+
+#include "base/memory/ref_counted_memory.h"
+#include "base/trace_event/trace_event_impl.h"
+#include "content/common/content_export.h"
+
+namespace base {
+class DictionaryValue;
+}
+
+namespace content {
+
+// BackgroundTracingConfig is passed to the BackgroundTracingManager to
+// setup the trigger rules used to enable/disable background tracing.
+struct CONTENT_EXPORT BackgroundTracingConfig
+    : public base::RefCountedThreadSafe<BackgroundTracingConfig> {

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

Why RefCounted? Seems overkill for a simple config struct.

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

Done.

+  enum Mode {
+    PREEMPTIVE_TRACING_MODE,
+    REACTIVE_TRACING_MODE,
+  };
+  enum CategoryPreset {
+    BENCHMARK,
+    BENCHMARK_DEEP,
+  };
+

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

Do you think we could get rid of the config base class and move the fields and
functionality from here into the manager interface or somewhere else?

The two tracing modes are fundamentally very different, and I think this adds
confusion.

Unless, you maybe want to specify this differently:
You have events (named manual, startup complete, histogram update) and actions:
finalize trace, enable tracing if needed. For finalizing the trace for the
latter, the enable action could either have a timeout argument for finalizing
(if that is the only way to use it you care about), or you could also support
specifying other events for the finalizing.

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

When we talked offline, we kicked around the idea of just separating these two
configs without a base class. We could do that, and just move the
Preemptive/Reactive configs into the manager interface, like:

class BackgroundTracingManager {
public:
 struct PreemptiveConfig {
   ...
 };
 struct ReactiveConfig {
   ...
 };

 bool StartInPremptiveMode(const PreemptiveConfig&,
scoped_refptr<BackgroundTracingUploadSink>);
 bool StartInReactiveMode(const ReactiveConfig&,
scoped_refptr<BackgroundTracingUploadSink>);
};

Also renamed the "SetActiveScenario" to "StartIn<X>Mode", feels like this is a
lot clearer what's happening? wdyt?

+  Mode mode;
+
+  static BackgroundTracingConfig* FromDict(const base::DictionaryValue* dict);
+  static void IntoDict(const BackgroundTracingConfig* config,
+                       base::DictionaryValue* dict);
+
+ protected:
+  friend class base::RefCountedThreadSafe<BackgroundTracingConfig>;
+
+  BackgroundTracingConfig(Mode mode);
+  virtual ~BackgroundTracingConfig();
+};
+
+}  // namespace content
+
+#endif  // CONTENT_PUBLIC_BROWSER_BACKGROUND_TRACING_CONFIG_H_