Re: [push-api] Identifying registrations

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
>
>