Adding user data to the notification options.

chrome/common/extensions/api/experimental_notification.idl

Index: chrome/common/extensions/api/experimental_notification.idl
diff --git a/chrome/common/extensions/api/experimental_notification.idl b/chrome/common/extensions/api/experimental_notification.idl
index 582c9b63153f69c753f10c17994e6f2836571a0d..7b8a431b250680e8e540c988b6756fe7eae0ddc3 100644
--- a/chrome/common/extensions/api/experimental_notification.idl
+++ b/chrome/common/extensions/api/experimental_notification.idl
@@ -68,6 +68,9 @@
 
     // Items for multi-item notifications.
     NotificationItem[]? items;
+
+    // User data for the notification.
+    DOMString? userData;

[dharcourt, 2013/02/22 21:35:30]

If this object will have the same restriction as the one passed in to
StorageArea.set() (chrome.storage.local and friends), we might want to document
that.  StorageArea.set() documents it as "Object specifying items to augment
storage with. Values that cannot be serialized (functions, etc) will be
ignored.". Sounds reasonable?

[vadimt, 2013/02/22 22:38:44]

Yes. Object is better than string.

   };
 
   callback CreateCallback = void (DOMString notificationId);
@@ -76,6 +79,10 @@
 
   callback DeleteCallback = void (boolean wasDeleted);
 
+  callback GetAllNotificationsCallback = void (
+      DOMString[] notificationsIds,
+      NotificationOptions[] notificationsOptions);
+

[dharcourt, 2013/02/22 21:35:30]

How about returning a notificationsInfo object which would be a map of
notification IDs to NotificationOptions? Alternatively, we could return an array
of NotificationInfo objects with each having an ID and options. Both seem easier
to work with than two synchronized arrays, and the array-of-info-objects
alternative would be more amenable to returning additional notification
information in the future without breaking APIs.

[vadimt, 2013/02/22 22:38:44]

Based on the offline discussion, it seems like we'll have a map from ID to user
data.

   interface Functions {
     // Creates and displays a notification having the contents in |options|,
     // identified by the id |notificationId|. If |notificationId| is empty,
@@ -98,6 +105,9 @@
     // corresponding notification. |callback| indicates whether a matching
     // notification existed.
     static void delete(DOMString notificationId, DeleteCallback callback);
+
+    // Returns to |callback| ids and options of all notifications.
+    static void getAllNotifications(GetAllNotificationsCallback callback);

[dharcourt, 2013/02/22 21:35:30]

How about getNotification(selector, callback), where selector is either an array
of notification IDs, a single notification ID string, or ""/undefined/null to
get all the notification IDs?

[vadimt, 2013/02/22 22:38:44]

My usecase requires only getting all notifications. But feel free to extend
this.
Actually, strictly and narrowly, I need only the list (or set) of IDs. Not even
user data IN THIS CALL. However, I guess, for symmetry, we should return same
info per notification as get reported to onClosed, onClicked and
onButtonClicked.

   };
 
   interface Events {
@@ -107,13 +117,18 @@
     static void onDisplayed(DOMString notificationId);
 
     // The notification closed, either by the system or by user action.
-    static void onClosed(DOMString notificationId, boolean byUser);
+    static void onClosed(DOMString notificationId,
+                         boolean byUser,
+                         NotificationOptions options);
 
     // The user clicked in a non-button area of the notification.
-    static void onClicked(DOMString notificationId);
+    static void onClicked(DOMString notificationId,
+                          NotificationOptions options);
 
     // The user pressed a button in the notification.
-    static void onButtonClicked(DOMString notificationId, long buttonIndex);
+    static void onButtonClicked(DOMString notificationId,
+                                long buttonIndex,
+                                NotificationOptions options);
   };
 
 };