Support needed to measure user and service traffic in Chrome.

components/data_use_measurement/core/data_use_user_data.h

Index: components/data_use_measurement/core/data_use_user_data.h
diff --git a/components/data_use_measurement/core/data_use_user_data.h b/components/data_use_measurement/core/data_use_user_data.h
new file mode 100644
index 0000000000000000000000000000000000000000..28dc89980750ba8166deb31460cac737ff0f11fa
--- /dev/null
+++ b/components/data_use_measurement/core/data_use_user_data.h
@@ -0,0 +1,45 @@
+// 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 COMPONENTS_DATA_USE_MEASUREMENT_CORE_DATA_USE_USER_DATA_H_
+#define COMPONENTS_DATA_USE_MEASUREMENT_CORE_DATA_USE_USER_DATA_H_
+
+#include "base/supports_user_data.h"
+
+namespace data_use_measurement {
+
+// Used to annotate URLRequests with the service name if the URLRequest is used
+// by a service.
+class DataUseUserData : public base::SupportsUserData::Data {

[mmenke, 2015/09/01 17:52:37]

UrlRequestSourceInfo?

[amohammadkhan, 2015/09/01 19:38:15]

I think if I don't make changes regarding your other comment, the current name
still makes sense. So I will change the name if later we decide to apply you
other comment about using ChromeResourceDispatcherHostDelegate and cover all the
sources by the enum of this class.

+ public:
+  // This enum should be synced with DataUseServices enum in histograms.xml.
+  // Please keep them synced after any updates. Also add service name to
+  // GetServiceName function.
+  enum ServiceType {

[mmenke, 2015/09/01 17:52:37]

Maybe rename to "source" and add a label for "OTHER_PROCESS"?  Then wouldn't
need to care about ResourceRequestInfo anywhere,
ChromeResourceDispatcherHostDelegate could just tag everything it sees.  Could
even separate out by process type, if it were useful.

[amohammadkhan, 2015/09/01 19:38:15]

It is very good that we can get rid of ResourceRequestInfo. But for now I prefer
to keep current way of detecting user data by using ResourceRequestInfo unless
one of reviewers thinks there is a big drawback in the current approach. 

+    NOT_TAGGED,
+    SUGGESTIONS,
+  };
+  explicit DataUseUserData(ServiceType service_type);
+  ~DataUseUserData() override;
+
+  ServiceType service_type() const { return service_type_; }
+
+  // The key for retrieving back this type of user data.
+  static const void* kUserDataKey;
+
+ private:
+  ServiceType service_type_;
+
+  DISALLOW_COPY_AND_ASSIGN(DataUseUserData);
+};
+
+// Helper function to create DataUseUserData. The caller takes the ownership of
+// the returned object.
+base::SupportsUserData::Data* CreateDataUseUserData(
+    DataUseUserData::ServiceType service);

[mmenke, 2015/09/01 17:52:37]

Rather than exposing the details of how this works (kUserDataKey, etc),

I'd suggest AttachSoureTypeToRequest(URLRequest*, SourceType) /
AttachDataUserUserDataToFetcher(URLFetcher*, SourceType) and
RecordUsageInformationForRequest(URLRequest*)  (The last would be a method of
the other class).

[amohammadkhan, 2015/09/01 19:38:15]

Good idea. I made the second function and used it in suggestion services too and
we already had the third function(But its name is a little different) and for
now we aren't attaching sourceType to any request, so I think it can be added
later.

+
+const char* GetServiceName(DataUseUserData::ServiceType service);
+
+}  // data_use_measurement namespace
+#endif  // COMPONENTS_DATA_USE_MEASUREMENT_CORE_DATA_USE_USER_DATA_H_