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

Re: [push-api] Identifying registrations

From: Michael van Ouwerkerk <mvanouwerkerk@google.com>
Date: Tue, 13 May 2014 14:39:12 +0100
Message-ID: <CAF40kP7CzLHAk7945=8j7Cpv16i5Pi23ePfaan7zqAbmMA5iEw@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Martin Thomson <martin.thomson@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>
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.

Please see this diagram for the full picture:
https://www.lucidchart.com/documents/view/5c9b43c3-cd0a-44f2-95aa-27a22dad2d95/0

For more context, here's the general design document for our implementation
in Chrome:
https://docs.google.com/a/chromium.org/document/d/1-YTIsnKfLfqELO54vo-lz3WaW2R8LARBpH0AZKkze4M/edit

I realize these are very Chrome specific, and implementations may differ,
but some concrete examples might help this discussion.

Regards,

Michael






On Tue, May 13, 2014 at 10:10 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Tue, May 13, 2014 at 1:08 AM, 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.
>
> Using URLs as identifiers is an anti-pattern which we should have
> learned by now.  In practice, multiple distinct URLs map to the same
> resource, and people understand this intuitively.  The fact that those
> multiple distinct URLs are multiple distinct identifiers is
> unintuitive and hard to use correctly, as XML Namespaces has taught us
> well over the years.
>
> (For example, the presence/absence of a slash at the end of a URL is
> almost never relevant in real life, but you have to memorize which
> pattern is used by a particular URL-as-identifier, and there's no
> real-life consensus about which to use.  Same with ordering of query
> params, http vs https, capitalization of domain name, etc.  The hash
> is relevant as an identifier, but not as a URL.  It's all terrible.)
>
> ~TJ
>
>
Received on Tuesday, 13 May 2014 13:39:40 UTC

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