W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

Push API register - vendor specific details

From: Michael van Ouwerkerk <mvanouwerkerk@google.com>
Date: Thu, 20 Mar 2014 15:19:00 +0000
Message-ID: <CAF40kP7uMd_j0Cnz2xRn0rVPKWtrNzuKM6tWsco0MXSk5ZvCzQ@mail.gmail.com>
To: public-webapps <public-webapps@w3.org>
To prevent abuse, many platforms require vendor specific registration
details for interacting with their push messaging systems. This allows e.g.
for banning spammers.

On Android, Google Cloud Messaging (GCM) is the canonical push messaging
system. Client registration requires passing a sender id and returns a
registration id:
http://developer.android.com/google/gcm/gs.html

iOS native apps:
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ProvisioningDevelopment.html

Safari Push Notifications (currently desktop only):
https://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/NotificationProgrammingGuideForWebsites/PushNotifications/PushNotifications.html#//apple_ref/doc/uid/TP40013225-CH3-SW1

This means that if the Push API is implemented around these systems, vendor
specific registration details must be provided.

How can we best manage the vendor specific details in the
navigator.push.register method?

The best suggestion I have heard is to give the register method a single
optional argument, which is a dictionary. Its attributes are optional and
it can be extended easily.

An example call might look like this:
navigator.push.register({
gcmSenderId: ‘some value’,
apnsPushId: ‘some other value’
});

I think this would be cleaner than e.g. user agent string parsing, and
serving different content based on that.

What do you think?

Regards,

Michael
Received on Thursday, 20 March 2014 15:19:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:22 UTC