Re: Push API register - vendor specific details

If we can automate and standardize the server-side registration
procedure then potentially we could use have an API which signals
"please do server side registration at this URL". The server side
registration would then return the identifier that could be passed to
push.register(). This way end-to-end registration can be fully
automated.

On one had, if both ends of registration can be fully automated, then
doesn't that defeat the purpose of the registration (which as I
understand it is to enable blocking spammers). On the other hand, I'm
guessing Google already uses a fully automated registration procedure?

/ Jonas


On Mon, Mar 24, 2014 at 6:57 AM, Michael van Ouwerkerk
<mvanouwerkerk@google.com> wrote:
> 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
>
>

Received on Monday, 24 March 2014 19:21:10 UTC