Added class to subscribe to GCD notifications over XMPP.

remoting/host/gcd_notification_subscriber.h

Index: remoting/host/gcd_notification_subscriber.h
diff --git a/remoting/host/gcd_notification_subscriber.h b/remoting/host/gcd_notification_subscriber.h
new file mode 100644
index 0000000000000000000000000000000000000000..91e1990369100b4a007b8f626c13f88362341b1b
--- /dev/null
+++ b/remoting/host/gcd_notification_subscriber.h
@@ -0,0 +1,45 @@
+// Copyright (c) 2015 The Chromium Authors. All rights reserved.

[Sergey Ulanov, 2015/05/07 18:22:39]

remove (c)

[John Williams, 2015/05/15 00:51:12]

Done.

+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef REMOTING_HOST_GCD_NOTIFICATION_SUBSCRIBER_H_
+#define REMOTING_HOST_GCD_NOTIFICATION_SUBSCRIBER_H_
+
+#include <string>
+
+#include "base/basictypes.h"
+#include "base/memory/scoped_ptr.h"
+#include "remoting/signaling/signal_strategy.h"
+
+namespace remoting {
+
+class IqSender;
+class IqRequest;
+
+// An object that subscribes to notifications from GCD using an XMPP
+// channel.  No actual notifications are used as of this writing, but

[Sergey Ulanov, 2015/05/07 18:22:39]

s/as of this writing/currently/ or just remove this sentence.

[John Williams, 2015/05/15 00:51:12]

Done.

+// the subscription is necessary in order for GCD to consider a device
+// online.
+class GcdNotificationSubscriber : public SignalStrategy::Listener {

[Sergey Ulanov, 2015/05/07 18:22:38]

Is the intent to make have a separate class receive notifications? If yes, then
why? I'd prefer having the same class subscribe and listen for notifications.
And then it should be called Receiver instead of Subscriber.

I think this class can be more generic and usable for any push notifications. It
doesn't need to be GCD-specific. Maybe call it PushNotificationReceiver and make
it work for any push notifications?

E.g. see jingle/notifier/listener/push_notifications_subscribe_task.cc - that
code is used by sync and CloudPrint to receive push notification. Similarly you
can pass list of notifications the caller want's to receive.
jingle/notifier is in a semi-deprecated state (because the XMPP code it depends
on in WebRTC is deprecated). In future I'd like to move remoting/signaling
somewhere where it can be reused by other components (e.g. components/xmpp) and
then this class will be a replacement for the current push notifications code in
jingle/notifier. 

Also please move this file to remoting/signaling.

[John Williams, 2015/05/15 00:51:12]

The reason I called it "subscriber" is that it literally just subscribes; it
doesn't even have any logic to detect when an XMPP stanza is a notification,
because none of the notifications GCD sends are useful to us. It's likely we'll
never need to process GCD notifications, since we're sending commands over the
raw XMPP channel rather than using GCD's "command" API.

[Sergey Ulanov, 2015/05/15 18:22:36]

I still think it's worth making this class more generic as I described in my
previous comment. You don't need to make it receive and process notifications.
Just rename it PushNotificationSubscriber and pass list of subscriptions from
outside instead of hardcoding it in this class.

[John Williams, 2015/05/15 21:59:42]

Done.

+ public:
+  GcdNotificationSubscriber(SignalStrategy* signal_strategy);
+  ~GcdNotificationSubscriber() override;
+
+  // SignalStrategy::Listener interface.
+  void OnSignalStrategyStateChange(SignalStrategy::State state) override;
+  bool OnSignalStrategyIncomingStanza(const buzz::XmlElement* stanza) override;
+
+ private:
+  void OnSubscriptionResult(IqRequest* request,
+                            const buzz::XmlElement* response);
+
+  SignalStrategy* signal_strategy_;
+  scoped_ptr<IqSender> iq_sender_;
+  scoped_ptr<IqRequest> iq_request_;
+
+  DISALLOW_COPY_AND_ASSIGN(GcdNotificationSubscriber);
+};
+
+}  // namespace remoting
+
+#endif  // REMOTING_HOST_GCD_NOTIFICATION_SUBSCRIBER_H_