Re: Progress on Push API

I'll give it a shot to define an outline here.

The problem that we're trying to solve is to let a webpage know when
it needs to register for push notifications. This happens either when
the page never has registered, or if the push server lost track of the
registration that was previously done.

Proposal A
One approach to this would be something like this:

interface PushManager {
  ...
  readonly attribute Promise registrationNeeded;
}

The returned promise would be resolved as soon as the UA determines
that this website never has done a registration, or that the
registration that was done was lost by the server.

The resulting code would look something like

navigator.push.registrationNeeded.then(() => {
  return navigator.push.register();
}).then(endpoint => {
  sendBackToAppServer(endpoint);
});

However ideally the page should also handle the server loosing the
registration multiple times during even the lifetime of a single page.
We could handle this by having the attribute return a new Promise any
time registration happens. This new promise would get resolved if
reregistration is needed. This gets a little messier with this
approach.

function registrationHandler() {
  navigator.push.register().then((endpoint) => {
   sendBackToAppServer(endpoint);
   navigator.push.registrationNeeded.then(registrationHandler);
  }
}
navigator.push.registrationNeeded.then(registrationHandler);


Another option is something like this:

interface PushManager {
  ...
  registrationRequired(callback);
}

The callback would get called any time that (re-)registration is needed.

navigator.push.registrationRequired(() => {
  navigator.push.register().then((endpoint) => {
    sendBackToAppServer(endpoint);
  });
});

We could even simplify the flow even more by combining the
registrationRequired and register() functions into something like
this:

navigator.push.registrationRequired((endpoint) => {
  sendBackToAppServer(endpoint);
});

In this case (re-)registration happens automatically. If
registrationRequired is called when a registration already exists,
then it does nothing. But if no registration has been done, or if/when
the server looses the existing registration, the callback is called.

If we go with an API like this, we'd likely need to enable forcefully
re-registering in case the app has lost track of the registration.
Something like this could work but is pretty ugly.

navigator.push.registrationRequired((endpoint) => {
  sendBackToAppServer(endpoint);
}, { forceReregister: true });

/ Jonas

On Wed, Apr 30, 2014 at 12:25 AM, EDUARDO FULLEA CARRERA <efc@tid.es> wrote:
> On 30 abr 2014 at 00:13:14, Jonas Sicking wrote:
>> On Tue, Apr 29, 2014 at 2:00 AM, EDUARDO FULLEA CARRERA <efc@tid.es>
>> wrote:
>>> Hi all,
>>>
>>> Last week the Push API editors (AT&T, Telefónica) and other interested
>> parties (Mozilla, Google) met to progress this specification. It was a very
>> productive meeting in which great support was shown to this piece of work and
>> consensus was reached around many topics under discussion. This is a summary
>> of these points, which will be incorporated into a new editor's draft shortly. Of
>> course feel free to provide any feedback:
>>
>
> We developing the new version at [1], though not yet updated with the changes in my previous email.
>
> But if may be a good idea to migrate is to the W3C GitHub official repo. What is the process to open the project there? Can anyone help?
>
> Thanks.
> Eduardo.
>
> [1] https://github.com/telefonicaid/WebAPISpecs/tree/develop/Push
>
> ________________________________
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Received on Thursday, 1 May 2014 23:56:49 UTC