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

Re: [push-api] Identifying registrations

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 13 May 2014 11:10:40 +0200
Message-ID: <CAAWBYDC88muEL+HepaA_pOVfHh1n+uUVCwgRQuEwY04nvcu6ew@mail.gmail.com>
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 (ATTCINW)" <bs3131@att.com>, Doug Turner <dougt@mozilla.com>
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 09:11:33 UTC

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