- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 20 Mar 2014 12:35:41 -0700
- To: Michael van Ouwerkerk <mvanouwerkerk@google.com>
- Cc: public-webapps <public-webapps@w3.org>
On Thu, Mar 20, 2014 at 8:19 AM, Michael van Ouwerkerk <mvanouwerkerk@google.com> wrote: > An example call might look like this: > navigator.push.register({ > gcmSenderId: 'some value', > apnsPushId: 'some other value' > }); Let me play devil's advocate a bit. We have already given up on having the "server side" of push as a standardized protocol for now. It seems like we are now doing the same with the client side. Given this, what is the advantage of having a push specification on the form of what you are proposing, over having a push API that simply looks like x = navigator.pushProtocol; // "gcm", "apns", "mozillapush" So the whole spec would be that single property. Possibly we would also define the name for the ServiecWorker event that is used to notify about incoming notifications. After a page checks that property, it could then call a protocol specific API and pass protocol specific arguments in order to do any registration. Or if the protocol doesn't require a registration then the page can simply do nothing. In order to push a message would send a protocol specific network message to a protocol server. You would then get the defined event in the ServiceWorker, but this event contains protocol specific data. If the protocol supports delivering a message body, then this body is included in the event. In fact, if we encourage different protocol implementors to use different names for the "register push" function, then we could use normal feature detection (`if ("registerGCMPush" in navigator)`) and get rid of the navigator.pushProtocol property too. >From a developer point of view, what would be the difference between what you are proposing and this approach? Possibly you'd have to write a slightly larger switch statement because the "register for push" function might have different names in different protocols. But the upshot is that we can make both registration and message delivery have access to more protocol-specific features. Neither approach really feels like a "standard" though. And both solutions sets a bit of a scary precedence. The web succeeded in part because it was based on standards. Standards that made the same code run across all browsers that implemented that standard. That said, I definitely appreciate the desire to integrate with existing push servers. But I don't know how to do that while really sticking with the goal of having a standardized web. / Jonas
Received on Thursday, 20 March 2014 19:36:42 UTC