Intent to Deprecate: PushSubscription.subscriptionId

[Peter Beverloo]

Contact emails

pe...@chromium.org

Spec

https://w3c.github.io/push-api/#pushsubscription-interface

Summary

When a developer subscribes to receive push messages, the interface currently exposes “endpoint” and “subscriptionId” as two separate properties.

We would like to merge the two, and only expose “endpoint” going forward. It will be a full URL containing both the endpoint and the subscription Id. This provides better forward compatibility, as the distinction will become much less relevant when the IETF server-to-server protocol has been standardized and implementations begin rolling it out.

In Chrome 44 we’d like PushSubscription.endpoint to contain *both* the endpoint and subscriptionId, with a deprecation warning when the developer accesses the subscriptionId independently. In Chrome 45, we’ll remove PushSubscription.subscriptionId entirely.

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes - minus Android WebView because we don’t support the Push API there.

Compatibility Risk

Medium. We are the only ones who ship the Push API, and this is a specified iteration on our implementation. Mozilla has been driving the merge of these two properties.

OWP launch tracking bug?

https://crbug.com/477401

Link to entry on the feature dashboard

None.

[PhistucK]

If this is approved, can you just merge it immediately to Chrome 42? It was just released three days ago...

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Peter Beverloo]

That's good feedback, thank you!

Chrome 42 is out of the question, but we could consider pursuing merging to Chrome 43 if the API owners feel this is a good idea.

Our motivation for choosing Chrome 44 for deprecation, and then Chrome 45 for removal is that we deprecate and then break two parts of the Push API - this and userVisible. Doing so in the same release would mean we only have to ask developers to update their implementation once, while providing the appropriate warnings in the prior release.

An argument for merging to Chrome 43 would be that there are less implementations around today, the impact would be lower. That said, while the patch will be small and trivial, merging will not have the preference of our TPMs. Merging the userVisible changes is definitely out of the question as well due to their size.

Advice from the API owners on this would be most welcome!

Thanks,

Peter

[Paul Kinlan]

Can you add this Intent to deprecation to ChromeStatus.

[Peter Beverloo]

Certainly!

https://www.chromestatus.com/feature/5283829761703936

Thanks,

Peter

[Paul Kinlan]

Thanks.  Just checked and it is in the new RSS feed for deprecations and removals: https://www.chromestatus.com/features.xml?status=Deprecated,Removed

[Chris Harrelson]

LGTM

It's better to give a longer deprecation period when possible, so I support deprecating in M43 and removing in M45, along with userVisible.

[Philip Jägenstedt]

Also LGTM.

If you want to put a date in the deprecation message, M45 will likely be released in August and M46 likely in October, based on my guesswork. One or two release cycles of deprecation both seem OK. If your hunch is that not much content can depend on PushSubscription.subscriptionId then getting rid of it fast reduces the risk that more content will come to depend on it.

Philip

On Fri, Apr 17, 2015 at 7:15 PM, Chris Harrelson <chri...@chromium.org> wrote:

LGTM

It's better to give a longer deprecation period when possible, so I support deprecating in M43 and removing in M45, along with userVisible.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[crh...@google.com]

Hey guys, I was wondering how this affects the server side. Most importantly, the server response format and handling, which is currently done as described in https://developer.android.com/google/gcm/http.html#response

How close is it going to be to the spec https://tools.ietf.org/html/draft-thomson-webpush-http2-02?

[Peter Beverloo]

Hi Alex,

Rather than receiving both an endpoint and a subscription Id, the application server now has to manually parse the subscription Id from the endpoint if the push service requires this.

When using GCM, this presents a bit more work in the near term, but having two separate values is likely to be incompatible and definitely not idiomatic when using the IETF Web Push protocol.

On the application server -> push service side, nothing will change and the proprietary GCM protocol still has to be used. We'll definitely keep blink-dev@ in the loop regarding any updates there.

Thanks,

Peter

[Alex Vaghin]

Yeah, makes sense. I also talked to @gauntface and @wibblymat today, which made things even more clear. Exciting.

Thanks!

[Peter Beverloo]

Friendly ping - this is still missing one LGTM.

Thanks,

Peter

[Mat]

If I have code that I expect to run on both 43 and 44, what is the best way to detect how to handle the endpoint?

[Peter Beverloo]

I would suggest merging the values manually if |subscriptionId| exists and is not included in |endpoint|.

serviceWorkerRegistration.pushManager.subscribe(..).then(function(subscription) {

  var endpoint = subscription.endpoint;

  if ('subscriptionId' in subscription && !endpoint.includes(subscription.subscriptionId))

    endpoint += "/" + subscription.subscriptionId;

  // use |endpoint| rather than |subscription.endpoint|

});

Thanks,

Peter

[TAMURA, Kent]

Deprecation and remove LGTM.

--

TAMURA Kent
Software Engineer, Google

[Peter Beverloo]

Thank you all!

The merger has been done per the following CL.

  https://src.chromium.org/viewvc/blink?revision=194922&view=revision

Thanks,

Peter