W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: [push-api] Identifying registrations

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 13 May 2014 10:10:09 -0700
Message-ID: <CABkgnnWGerQLjH7q5ZreO6pTNrmtKqCk4ZxENuSF9fxfR59GVA@mail.gmail.com>
To: Michael van Ouwerkerk <mvanouwerkerk@google.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>, EDUARDO FULLEA CARRERA <efc@tid.es>, "SULLIVAN, BRYAN L (ATTCINW)" <bs3131@att.com>, Doug Turner <dougt@mozilla.com>
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.
Received on Tuesday, 13 May 2014 17:10:37 UTC

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