Initial RemoteCommandService

components/policy/core/common/cloud/cloud_policy_client.h

Index: components/policy/core/common/cloud/cloud_policy_client.h
diff --git a/components/policy/core/common/cloud/cloud_policy_client.h b/components/policy/core/common/cloud/cloud_policy_client.h
index fbc215def972becff2ada99a32ad7e550c8500a6..72544daab8ec9524bf792d2a4565f0033702a6b1 100644
--- a/components/policy/core/common/cloud/cloud_policy_client.h
+++ b/components/policy/core/common/cloud/cloud_policy_client.h
@@ -146,6 +146,9 @@ class POLICY_EXPORT CloudPolicyClient {
   virtual void UploadCertificate(const std::string& certificate_data,
                                  const StatusCallback& callback);
 
+  // XXX
+  virtual scoped_ptr<DeviceManagementRequestJob> CreateRemoteCommandsJob();

[bartfab (slow), 2015/01/29 10:18:05]

Why not have this method create a job and send it to the outbound queue in one
go?

[binjin, 2015/01/29 10:44:10]

That will introduce some logic about how to construct the remote command request
header into policy specified code, which is what I try to avoid.

[bartfab (slow), 2015/01/29 15:28:58]

If you look at Drew's solution, this is exactly what he does:

https://codereview.chromium.org/845313008/diff/160001/components/policy/core/...

He passes two protos that the CloudPolicyClient stuffs into the command before
sending it off. I think it is a good idea to be consistent with that approach
for remote commands as well. The logic that actually builds these protos does
not belong into the client. The client simply copies them over and sends the
result.

+
   // Adds an observer to be called back upon policy and state changes.
   void AddObserver(Observer* observer);