[OBSOLETE] Reporting: Initial implementation.

net/reporting/reporting_metrics.h

Index: net/reporting/reporting_metrics.h
diff --git a/net/reporting/reporting_metrics.h b/net/reporting/reporting_metrics.h
new file mode 100644
index 0000000000000000000000000000000000000000..5461009a9acfbdd4cae9fb3a30a937135d528149
--- /dev/null
+++ b/net/reporting/reporting_metrics.h
@@ -0,0 +1,80 @@
+// Copyright 2016 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 NET_REPORTING_REPORTING_METRICS_H_
+#define NET_REPORTING_REPORTING_METRICS_H_
+
+#include "base/time/time.h"
+
+namespace net {
+
+enum EnabledState {

[Ryan Sleevi, 2017/01/03 21:28:13]

1) Do all of these need to be in "public" headers? Ideally, no.
2) Document - none of these states are self-obvious

[Julia Tuttle, 2017/01/25 20:27:45]

They don't need to be visible outside //net, no. What makes a header file
"public"?
Is it good or bad to let histograms.xml be the canonical documentation for the
states?

+  ENABLED_STATE_DISABLED_DEFAULT,
+  ENABLED_STATE_ENABLED_DEFAULT,
+  ENABLED_STATE_DISABLED_FIELD_TRIAL,
+  ENABLED_STATE_ENABLED_FIELD_TRIAL,
+  ENABLED_STATE_DISABLED_COMMAND_LINE,
+  ENABLED_STATE_ENABLED_COMMAND_LINE,
+  ENABLED_STATE_MAX
+};
+
+enum HeaderFate {
+  HEADER_FATE_DROPPED_NO_SERVICE,
+  HEADER_FATE_REJECTED_INSECURE_ORIGIN,
+  HEADER_FATE_REJECTED_INVALID_JSON,
+  HEADER_FATE_ACCEPTED_WITH_INVALID_ENDPOINT,
+  HEADER_FATE_ACCEPTED,
+  HEADER_FATE_MAX,
+};
+
+enum HeaderEndpointFate {
+  HEADER_ENDPOINT_FATE_SET_ENDPOINT_CREATED,
+  HEADER_ENDPOINT_FATE_SET_CLIENT_CREATED,
+  HEADER_ENDPOINT_FATE_SET_CLIENT_UPDATED,
+  HEADER_ENDPOINT_FATE_CLEAR_NO_ENDPOINT,
+  HEADER_ENDPOINT_FATE_CLEAR_NO_CLIENT,
+  HEADER_ENDPOINT_FATE_CLEAR_CLIENT_REMOVED,
+  HEADER_ENDPOINT_FATE_MAX,
+};
+
+enum ReportFate {
+  REPORT_FATE_DELIVERED,
+  REPORT_FATE_FAILED,
+  REPORT_FATE_EXPIRED,
+  REPORT_FATE_EVICTED,
+  REPORT_FATE_SHUTDOWN,
+  REPORT_FATE_MAX,
+};
+
+enum DeliveryFate {
+  DELIVERY_FATE_SUCCESS,
+  DELIVERY_FATE_FAILURE,
+  DELIVERY_FATE_SHUTDOWN,
+  DELIVERY_FATE_MAX
+};
+
+enum EndpointFate {
+  ENDPOINT_FATE_REQUESTED_REMOVAL,
+  ENDPOINT_FATE_EXPIRED,
+  ENDPOINT_FATE_UNUSED,
+  ENDPOINT_FATE_FAILED,
+  ENDPOINT_FATE_EVICTED,
+  ENDPOINT_FATE_SHUTDOWN,
+  ENDPOINT_FATE_MAX,
+};
+
+void HistogramEnabledState(EnabledState state);

[Ryan Sleevi, 2017/01/03 21:28:13]

naming/design:

It seems not at all self-obvious when reading code and seeing a call to 

net::HistogramEnabledState(ENABLED_STATE_ENABLED_DEFAULT)

is going to do, documentation or not. It seems like much of this may be better
served being grouped in a logical namespace (net::reporting)?

In thinking very carefully how //net will be used in the future, does this API
benefit from splitting (like QUIC to some extent, and like //content
exclusively) into the notion of "public" and "private" implementation parts? It
seems like this bleeds a lot into a namespace without very clear naming.

[Julia Tuttle, 2017/01/25 20:27:45]

I think it totally would benefit from that, but I'm unsure how to do it. Is it
just enforced by custom (and presubmit) that stuff outside //content can't
depend on headers outside //content/public?

+void HistogramHeader(HeaderFate fate);
+void HistogramHeaderEndpoint(HeaderEndpointFate fate, base::TimeDelta ttl);
+void HistogramClient(base::TimeDelta ttl);
+void HistogramReport(ReportFate fate, base::TimeDelta latency, int attempts);
+void HistogramDeliveryContent(int report_count, int byte_count);
+void HistogramDeliveryOutcome(DeliveryFate fate,
+                              int net_error,
+                              int http_response_code);
+void HistogramEndpoint(EndpointFate fate);
+
+}  // namespace net
+
+#endif  // NET_REPORTING_REPORTING_METRICS_H_