Re: [push-api] Identifying registrations

Hi Martin, note that the latest proposal is to have only a single
registration at a time:
http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0223.html

This means that unregister can remain on PushManager and requires no
arguments.

Yesterday I also posted a github issue with the suggestion to change the
unregister return value:
https://github.com/w3c/push-api/issues/4

Respec was fixed recently to support parameterization after this discussion:
http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0697.html

Regards,

Michael






On Tue, May 13, 2014 at 6:10 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 13 May 2014 06:39, Michael van Ouwerkerk <mvanouwerkerk@google.com>
> wrote:
> > Martin, in Chrome we use registrationId and endpoint for distinct
> purposes.
> > The endpoint is the push server url to which the app server posts new
> > messages. The registrationId identifies the correct {device, user, page}
> to
> > which the message will be sent.
>
> I think that the spec needs to be a lot clearer on the purpose (and
> usage) of each of these things.  Personally, I think that a better
> model would be this:
>
> interface PushManager {
>   Promise<PushRegistration> register();
>   Promise<sequence<PushRegistration>> registrations();
> };
>
> interface PushRegistration {
>   Promise unregister();
>   attribute DOMString id;
>   attribute DOMString endpoint;
> };
>
> interface PushMessage {
>   attribute PushRegistration registration;
>   attribute ?? data;
> }
>
> Yes, aside from moving unregister, it's just names, but sometimes
> names are important.  The reason behind moving unregister being that
> 'id' is only present for bookkeeping purposes, and many apps won't
> have to use it.
>
> That said, looking at this, I am sorely tempted to suggest adding
> EventTarget to PushRegistration and use events.  Any reason that
> wouldn't be appropriate?
>
> p.s., I assume that the mess in the editor's draft regarding
> PushManager is due to a Respec.js issue around the use of promises.
>