Plumb invalidations from Tango to the extensions code for the Push Messaging API.

chrome/browser/sync/invalidation_service.h

Index: chrome/browser/sync/invalidation_service.h
diff --git a/chrome/browser/sync/invalidation_service.h b/chrome/browser/sync/invalidation_service.h
new file mode 100644
index 0000000000000000000000000000000000000000..38ad54801ac650f18725bf51cd9c59cd30fda6dd
--- /dev/null
+++ b/chrome/browser/sync/invalidation_service.h
@@ -0,0 +1,43 @@
+// Copyright (c) 2012 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 CHROME_BROWSER_SYNC_INVALIDATION_SERVICE_H_
+#define CHROME_BROWSER_SYNC_INVALIDATION_SERVICE_H_
+
+#include "sync/notifier/invalidation_util.h"
+
+namespace syncer {
+class SyncNotifierObserver;
+}  // namespace syncer
+
+// TODO(dcheng): Add an interesting comment here.

[Munjal (Google), 2012/08/14 18:56:37]

Did you mean to add a comment here before committing?

[dcheng, 2012/08/14 21:39:59]

I've replaced this with a slightly more helpful comment.

+class InvalidationService {
+ public:
+  virtual ~InvalidationService() { }
+  // Starts sending notifications to |handler|.  |handler| must not be NULL,
+  // and it must already be registered.

[Munjal (Google), 2012/08/14 18:56:37]

This comment is a bit confusing. Comment says the handler must alredy be
registered, but this method seems to be the one that can register a new handler.
?

[dcheng, 2012/08/14 21:39:59]

Hmm. I copied these comments frmo ProfileSyncService... but it does read a
little oddly. I'll talk with Fred about this.

+  //
+  // Handler registrations are persisted across restarts of sync.
+  virtual void RegisterInvalidationHandler(
+      syncer::SyncNotifierObserver* handler) = 0;
+
+  // Updates the set of ObjectIds associated with |handler|.  |handler| must
+  // not be NULL, and must already be registered.  An ID must be registered for
+  // at most one handler.
+  //
+  // Registered IDs are persisted across restarts of sync.
+  virtual void UpdateRegisteredInvalidationIds(
+      syncer::SyncNotifierObserver* handler,
+      const syncer::ObjectIdSet& ids) = 0;

[Munjal (Google), 2012/08/14 18:56:37]

Could we instead expose methods to add and remove object ids the handler is
listening for?

[dcheng, 2012/08/14 21:39:59]

This is how the interface looks for now. It was chosen since it was likely that
most handlers would have to keep track of what was registered themselves anyway.

If it simplifies the implementation of a lot of SyncNotifierObservers, it's
possible we'll change this but that won't happen in this CL.

+
+  // Stops sending notifications to |handler|.  |handler| must not be NULL, and
+  // it must already be registered.  Note that this doesn't unregister the IDs
+  // associated with |handler|.

[Munjal (Google), 2012/08/14 18:56:37]

So are object ids shared across handlers? Or in other words, can multiple
handlers listen to the same object ids?

If that is the case, what happens when one handler stops listening to some
object ids? Does InvalidationService unregister for that object id? Or does it
keep track of all handlers for that object id and unregister for the object id
if there is no handler for that?

I am just trying to understand if there is a way to simplify the semantics here
a little bit.

[dcheng, 2012/08/14 21:39:59]

No. "An ID must be registered for at most one handler."
This is used for shutdown. When Unregister() is called, all existing
registrations for a handler are orphaned. The intended use is to avoid a lot of
re-registration traffic when Chrome is restarted. See
http://code.google.com/p/chromium/issues/detail?id=140325

+  //
+  // Handler registrations are persisted across restarts of sync.
+  virtual void UnregisterInvalidationHandler(
+      syncer::SyncNotifierObserver* handler) = 0;
+};
+
+#endif  // CHROME_BROWSER_SYNC_INVALIDATION_SERVICE_H_