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. <[email protected]>wrote: > On Tue, May 13, 2014 at 1:08 AM, Martin Thomson > <[email protected]> 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 > >
