- From: Doug Turner <dougt@mozilla.com>
- Date: Mon, 12 May 2014 18:43:31 -0700
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>, EDUARDO FULLEA CARRERA <efc@tid.es>, "SULLIVAN, BRYAN L" <bs3131@att.com>, Doug Turner <dougt@mozilla.com>
The thinking behind this would be that people might use the
pushEndpoint as the 'type' of push notification service you are
talking to (gcm, mozilla, samsung, apple, etc) and the
pushRegistrationID as the identifier. Doing it this way avoids having
to parse URLs... sorta.
On Mon, May 12, 2014 at 4:08 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> The push API currently identifies a registration with a tuple:
>
> interface PushRegistration {
> readonly attribute DOMString pushEndpoint;
> readonly attribute DOMString pushRegistrationId;
> };
>
> It looks like both are used by the push server. Local methods seem to
> rely on the pushRegistrationId; the remote application server uses the
> pushEndpoint, though details are not currently specified [1].
>
> In my experience, the pushEndpoint is a sufficiently unique
> identifier. Contingent on some conclusions on the protocol side, this
> could be defined as a URL and used as an identifier. That single
> identifier should suffice.
>
> --Martin
>
> p.s., the register() method on PushManager should be updated to return
> Promise<PushRegistration> or Promise<DOMString> as appropriate.
>
> [1] see webpush@ietf.org and related effort there
Received on Tuesday, 13 May 2014 01:44:18 UTC