Re: Push API register - vendor specific details

Jonas, your suggestions have a good point. I don't yet see a way around
having a sender id or push id though. I'll keep looking for a way to reduce
proprietary pieces in the API. But for the moment, the Push API as it is
seems hard to implement without proprietary extensions to it.

Thanks for your detailed reply.

/m



On Thu, Mar 20, 2014 at 7:35 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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
>