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

Re: Push API register - vendor specific details

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 20 Mar 2014 12:35:41 -0700
Message-ID: <CA+c2ei_KTEahrZFgP=vp+hHGR5PtaqnmGXxssCj8j+LZxhSx9Q@mail.gmail.com>
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

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