Intent to implement: Push API

[Michael van Ouwerkerk]

Contact emails

mvanou...@chromium.org, joh...@chromium.org

Spec

https://dvcs.w3.org/hg/push/raw-file/tip/index.html

Summary

Provides a way for a web app to receive push messages from the app server. We are working with the spec editor to make this work based on Service Workers. When a message is received, an event will be fired in a Service Worker. The SW will be brought up if it is not yet running.

Motivation

This system enables communication from server to page (via a Service Worker) even when the page is not running. This new capability is a popular request from web developers.

An example use case would be an email app that receives a push message about a new email in the background. Messages can have a limited payload, or data can be fetched in the background in response to the push message.

Compatibility Risk

Medium.

There is an implementation of an early version of the specification in Firefox OS: https://developer.mozilla.org/en-US/docs/Web/API/Navigator.push

The Push API has a dependency on ServiceWorker: https://github.com/slightlyoff/ServiceWorker/ - its implementation in Blink/Chromium and standardization are incomplete but making good progress.

We expect to make some changes in the Push API specification based on implementation experience.

Ongoing technical constraints

None.

Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes. On Android, we will integrate this with the GCM framework in Java. On all other platforms, we will generalize the infrastructure that is already in place for Chrome apps and extensions.

OWP launch tracking bug?

https://code.google.com/p/chromium/issues/detail?id=349474

Link to entry on the feature dashboard

http://www.chromestatus.com/features/5416033485586432

Requesting approval to ship?

No.

[Dmitry Titov]

While I understand the genesis of this proposal (I think), it is still strange to see Push APIs to multiply.

We are about to ship chrome.gcm which is intentionally a close replica of Android GCM Java API. It likely will be mentioned on I/O and it is what users of previous chrome.pushMessaging asked for. There were documented reasons for doing it and the they are not invalid for the Web as well. Certainly, Android GCM gained a lot of momentum (33B messgaes/day currently, ~100k Apps using it) and it means there is a lot of developer expertise, pushing servers and somewhat of a 'network effect'. The GCM API is much more mature, 2-way, collapsible, has TTL support, reliable queues, payloads and will support encryption in a few weeks... Those features are reflected in API itself, they are added over long time following requests from developers. I am not sure how to map the proposed API into GCM underlying transport and server-side API w/o 'seams' and loss of functionality.

Looking at the proposed API, it strikes me as a "back to beginning", years back, kind of ignoring the accumulated experience, good or bad. Likely the similar learning curve will follow (pushed by the same developers who are using GCM now), causing yet another team to go through the same exercise. Can/should we combine efforts to see if we can come up with offering that might have momentum from the start and is less confusing?

I understand there is traditional push against "Google only" things, but in this space we can lead innovation and standardization on the basis of existing experience, which IMO is a good thing. GCM is ahead of anything out there in terms of push, both functionally and by usage - why throw it away instead of riding it and making it a basis for standardization for Web platform?

Thoughts?

[Michael[tm] Smith]

Dmitry Titov <dim...@chromium.org>, 2014-03-20 16:18 -0700:

> On Wed, Mar 5, 2014 at 10:00 AM, Michael van Ouwerkerk wrote:
> > Spec
> > https://dvcs.w3.org/hg/push/raw-file/tip/index.html
> >
> > Summary
> > Provides a way for a web app to receive push messages from the app server.
> > We are working with the spec editor to make this work based on Service
> > Workers. When a message is received, an event will be fired in a Service
> > Worker. The SW will be brought up if it is not yet running.
> >
> > Motivation
> > This system enables communication from server to page (via a Service
> > Worker) even when the page is not running. This new capability is a popular
> > request from web developers.
>

> While I understand the genesis of this proposal (I think), it is still
> strange to see Push APIs to multiply.
>

> We are about to ship chrome.gcm<https://developer.chrome.com/apps/cloudMessagingV2>

> which is intentionally a close replica of Android GCM Java API.

Is the chrome.gcm API usable (or planned to become usable) with normal web
applications on the actual ("drive by") Web?

I notice at https://developer.chrome.com/apps/cloudMessagingV2#enable_gcm
it says that step 1 is "Upload your app or extension client to the Chrome
Web Store". So unless I'm mistaken, it seems like a fundamental difference
at this point at least is that the Push API enables push notifications to
be sent for normal webapps, while the chrome.gcm API doesn't (yet).

> I am not sure how to map the proposed API into GCM underlying transport
> and server-side API w/o 'seams' and loss of functionality.
>
> Looking at the proposed API, it strikes me as a "back to beginning", years
> back, kind of ignoring the accumulated experience, good or bad.

Yeah, I think the work on the Push API was probably not informed nearly as
much as it should have been by more recent work Google Cloud Messaging and
whatever the equivalent iOS thing is. But as far as I can see, we still
have time and flexibility to rework the Push API into something much better
aligned with current experience.

> Can/should we combine efforts to see if we can come up with offering that
> might have momentum from the start and is less confusing?
>
> I understand there is traditional push against "Google only" things, but in
> this space we can lead innovation and standardization on the basis of
> existing experience, which IMO is a good thing. GCM is ahead of anything
> out there in terms of push, both functionally and by usage - why throw it
> away instead of riding it and making it a basis for standardization for Web
> platform?

I totally agree here, fwiw. GCM is great, so if we could make a standard
web-platform API in a way that its Chrome implementation could be hooked
into GCM, it seems like that'd be a big win.

--Mike

--
Michael[tm] Smith http://people.w3.org/mike

[Peter Beverloo]

Hi Dmitry,

Thank you for your feedback! Looking at the chrome.gcm API, I can see the following differences with our current Push API plans:

    * The chrome.gcm.register() call allows more than a single sender Id to be specified.

What is the primary benefit of supporting multiple sender Ids? Michael sent a proposal to public-webapps yesterday for specifying vendor-specific registration Ids (which, in the current world, are unfortunately necessary). In the proposal these are strings, but if we see strong benefits in having the ability to specify multiple sender Ids then our Blink implementation could support both a string or an array.

    * chrome.gcm exposes a MAX_MESSAGE_SIZE constant for exposing the maximum message size.

Given some of the differences between push servers, e.g. GCM supporting messages up to 4kb, APNS supporting messages up to 256 bytes, as well as giving the implementation a chance to update these limits whenever the push server's allowances change, this might be interesting to support.

One important thing to note here is that there various active discussions about how we (parties interested in bringing Push Messaging to the Web) should proceed with standardizing the client-side API. Mozilla's Jonas Sicking suggested a scenario in which each push server would implement a protocol-specific API, because pursuing standardization of the server-sided protocol has so far been considered out of scope. That seems to match your proposal.

I believe that a very good starting point would be a situation in which the client-side API is the same regardless of which push protocol is being used, minimizing the vendor-specific footprint. This would allow developers to use the exact same JavaScript code regardless of the push server used by the implementation. This gives us a lot of flexibility to improve *and* incentive on this situation in the future.

Without having both a standardized protocol and a shared sender registry, the vendor-specific sender information (sender Id for GCM, appKey for APNS) has to be provided on the client to meet requirements of all major push services. We're looking at possibilities for specifying the push server protocol, but this has many, many unsolved issues. Feel free to reach out directly if you'd like to know more :-).

    * The GCM API supports Google Cloud Messaging's upstream channel.

I understand that the primary benefit of upstream messaging is the guaranteed delivery, whereas an XHR may fail. Since we're already using Service Workers as the message delivery mechanism, it wouldn't be very hard for developers to enqueue the request to be retried later on.

Furthermore, as far as I'm aware, GCM is the only push service supporting an upstream channel. That would impose a barrier for other implementations (which may not be based on GCM) to fully support a specification. If we start discussing specifying the push service's protocol, this will definitely be an important area of focus. 

    * The GCM API requires the user to be logged in to Chrome in order to use the functionality.

The Push API will not require the user to be logged in to Chrome.

To summarize, I don't agree that we're going "back to the beginning" with the client-sided API, since the two major differences are the absence of an upstream channel, and the (proposed) ability to only support a single sender Id. The addition of encryption is a very good thing, so that's something we'll definitely look into.

The story is more difficult on the server side, which is what I think you're getting at. The eventual goal of standardization would be to get rid of vendor-specific code throughout the entire path of a feature. While it would improve interoperability, specifying the server protocol would not solve that problem, because the second major vendor-specific extension is the addition of authentication information.

Developers being able to use identical code on the client is a big step towards solving the larger problem of having a single, unified path for pushing messages to any browser or device.

Thanks,

Peter

[Dmitry Titov]

I think publishing the app in store provides a unique app id, so it can be used during registration

process to identify the app as a receiving endpoint. On the Web, the origin can serve similar role.

 

> I am not sure how to map the proposed API into GCM underlying transport
> and server-side API w/o 'seams' and loss of functionality.
>
> Looking at the proposed API, it strikes me as a "back to beginning", years
> back, kind of ignoring the accumulated experience, good or bad.

Yeah, I think the work on the Push API was probably not informed nearly as
much as it should have been by more recent work Google Cloud Messaging and
whatever the equivalent iOS thing is. But as far as I can see, we still
have time and flexibility to rework the Push API into something much better
aligned with current experience.

> Can/should we combine efforts to see if we can come up with offering that
> might have momentum from the start and is less confusing?
>
> I understand there is traditional push against "Google only" things, but in
> this space we can lead innovation and standardization on the basis of
> existing experience, which IMO is a good thing. GCM is ahead of anything
> out there in terms of push, both functionally and by usage - why throw it
> away instead of riding it and making it a basis for standardization for Web
> platform?

I totally agree here, fwiw. GCM is great, so if we could make a standard
web-platform API in a way that its Chrome implementation could be hooked
into GCM, it seems like that'd be a big win.

  --Mike

--
Michael[tm] Smith http://people.w3.org/mike

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBCgAGBQJTK7PUAAoJEIfRdHe8OkuVNh0P/Ap+09QF7ULeHMFZ/u2SOiq8
vDu/tc8HJDVnXTDfYU6fgsyiZcosTlEz1oaa/zrUtipolFueKJgUbiiA9XCgxKHx
W8agUHHVp0611EuFi2ONXVG3zbCqy0Wj1/OinVT2rwbkTiL0mKf8cOZ8s/By3eqj
reVZ4sc0pukO9Fpy1exxiFcICHAzZhA9F6H/QuCGiEUKSmb4AvyaXP3tTENPT3QZ
wMMXhwpj0wfBzSxgul3isnWtD8Hop9YCu4SgMC3Nwvi8BltCb0vSZOE1BDOLH87K
JLq5HWF6X2LcvSDurJvgsLDTXwFGw2gnBqw+qY2ORQfO51u1cx4qkCBswfsOkobG
4/rC85Kya89gZUk3QQrDL+yVMyYSx4V903ELZQPsfhwGtjiLTbBQKs87tcQeY5MZ
a9tQqKSRbUHSAXlqQZj7l27i3K94nNrHeAIeDI9A9lBzdrIH2HoXWvpzJObh7QuQ
HwenA8KDL0cMG9p/GbDko9B0YGNFKyVkOfxiB+Hmsp1T70VABgAoHR5loGMS7tAR
xQI0Zw10itm35KeF+BaV8nVmDFpzGWHIORoEHYSstsInEblkhJSjZ629LU91haMf
FV/hHnuQarCDzEF0ERPP6ZF+NXC1MkhkfEYvG/4EHg3uM47FRIGmq8S8iLz5zUOw
T3pypTlQVZs5ptHcsBP8
=KVDL
-----END PGP SIGNATURE-----

[Dmitry Titov]

See inline...

On Fri, Mar 21, 2014 at 3:58 AM, Peter Beverloo <pe...@chromium.org> wrote:

Hi Dmitry,

Thank you for your feedback! Looking at the chrome.gcm API, I can see the following differences with our current Push API plans:

    * The chrome.gcm.register() call allows more than a single sender Id to be specified.

What is the primary benefit of supporting multiple sender Ids? Michael sent a proposal to public-webapps yesterday for specifying vendor-specific registration Ids (which, in the current world, are unfortunately necessary). In the proposal these are strings, but if we see strong benefits in having the ability to specify multiple sender Ids then our Blink implementation could support both a string or an array.

I don't have good data on how popular the multiple senders are in practice. They can be used for testing (with production and test servers having separate senderId), especially if it is desired to manage/secure API Keys separately (because API Keys are tied to a senderId which is a projectId in Google Dev Console). But once there are vendor-specific parameters passed into register() call, what's the big reason not to supply actual vendor-specific data, eg an array in case of gcm. Developers will likely find it more familiar.

    * chrome.gcm exposes a MAX_MESSAGE_SIZE constant for exposing the maximum message size.

Given some of the differences between push servers, e.g. GCM supporting messages up to 4kb, APNS supporting messages up to 256 bytes, as well as giving the implementation a chance to update these limits whenever the push server's allowances change, this might be interesting to support.

One important thing to note here is that there various active discussions about how we (parties interested in bringing Push Messaging to the Web) should proceed with standardizing the client-side API. Mozilla's Jonas Sicking suggested a scenario in which each push server would implement a protocol-specific API, because pursuing standardization of the server-sided protocol has so far been considered out of scope. That seems to match your proposal.

I believe that a very good starting point would be a situation in which the client-side API is the same regardless of which push protocol is being used, minimizing the vendor-specific footprint. This would allow developers to use the exact same JavaScript code regardless of the push server used by the implementation. This gives us a lot of flexibility to improve *and* incentive on this situation in the future.

Without having both a standardized protocol and a shared sender registry, the vendor-specific sender information (sender Id for GCM, appKey for APNS) has to be provided on the client to meet requirements of all major push services. We're looking at possibilities for specifying the push server protocol, but this has many, many unsolved issues. Feel free to reach out directly if you'd like to know more :-).

    * The GCM API supports Google Cloud Messaging's upstream channel.

I understand that the primary benefit of upstream messaging is the guaranteed delivery, whereas an XHR may fail. Since we're already using Service Workers as the message delivery mechanism, it wouldn't be very hard for developers to enqueue the request to be retried later on.

Not sure what you mean by easy enqueue here... It is actually hard to properly save context and implement some sort of retry with backoff combined with network state tracking, and it also hard to do in battery-efficient way. But I guess I'm arguing the general point of Push API not benefiting from protocol-specific goodness.

 

Furthermore, as far as I'm aware, GCM is the only push service supporting an upstream channel. That would impose a barrier for other implementations (which may not be based on GCM) to fully support a specification. If we start discussing specifying the push service's protocol, this will definitely be an important area of focus. 

    * The GCM API requires the user to be logged in to Chrome in order to use the functionality.

The Push API will not require the user to be logged in to Chrome.

While current implementation of GCM API in Chrome indeed requires sign in, it is technically possible to remove this requirement. I believe the investigation and issues to resolve here are going to be the same as for current spec of Push API. Note Google account is not a requirement for GCM on Android starting 4.0.4...

 

To summarize, I don't agree that we're going "back to the beginning" with the client-sided API, since the two major differences are the absence of an upstream channel, and the (proposed) ability to only support a single sender Id. The addition of encryption is a very good thing, so that's something we'll definitely look into.

What about "do-not-collapse" messages? This is a queue-based mechanism to deliver a small data stream to the app, with a special marker (exposed in client API) delivered to app when queue overflows - useful for apps like PushBullet because it can make their servers much more stateless. Also, TTL support seems to be useful, especially for TTL=0 case, which is "deliver now or drop", I can see games use this. Knowing these details of service behavior can affect how client is coded up.

 

The story is more difficult on the server side, which is what I think you're getting at. The eventual goal of standardization would be to get rid of vendor-specific code throughout the entire path of a feature. While it would improve interoperability, specifying the server protocol would not solve that problem, because the second major vendor-specific extension is the addition of authentication information.

Developers being able to use identical code on the client is a big step towards solving the larger problem of having a single, unified path for pushing messages to any browser or device. 

Thanks,

Peter

Speaking about registration, the spec seems to imply that an app can create multiple registrations. It is not clear to me how this will be reflected on a sending side of gcm for example. While there are collapse keys that can be used to 'emulate' the multiple registrations, the number is limited and such mapping can be pretty confusing. Do you have a plan how you will implement this feature on top of GCM?

Overall, I think it's a great goal to make push services to agree on common standards, but how would it work in practice?  The services are much different and still actively developing. This is also being done by a crowd different from traditional browser developers, so it'll take longer to bridge viewpoints. In meanwhile, if there are just 2 "de-facto standards" (GCM and APNS), I can see value in providing those "as is" to web developers instead of introducing a 3rd, which is somewhat a subset of both and very likely will be significantly changed during standardization process. You seem to prefer to standardize client API w/o touching server-side story for now... but:

- single client API won't be congruent to server-side API of any service and this will be very confusing for developers

- current Push API based on version numbers does not have precedent in existing systems... No payload is hard limitation

- it creates a new additional API for developers who likely already deal with most popular mobile push services.

Dmitry

 

[Peter Beverloo]

On Fri, Mar 21, 2014 at 10:03 PM, Dmitry Titov <dim...@chromium.org> wrote:

See inline...

On Fri, Mar 21, 2014 at 3:58 AM, Peter Beverloo <pe...@chromium.org> wrote:

Hi Dmitry,

Thank you for your feedback! Looking at the chrome.gcm API, I can see the following differences with our current Push API plans:

    * The chrome.gcm.register() call allows more than a single sender Id to be specified.

What is the primary benefit of supporting multiple sender Ids? Michael sent a proposal to public-webapps yesterday for specifying vendor-specific registration Ids (which, in the current world, are unfortunately necessary). In the proposal these are strings, but if we see strong benefits in having the ability to specify multiple sender Ids then our Blink implementation could support both a string or an array.

I don't have good data on how popular the multiple senders are in practice. They can be used for testing (with production and test servers having separate senderId), especially if it is desired to manage/secure API Keys separately (because API Keys are tied to a senderId which is a projectId in Google Dev Console). But once there are vendor-specific parameters passed into register() call, what's the big reason not to supply actual vendor-specific data, eg an array in case of gcm. Developers will likely find it more familiar.

Perhaps, but also less interoperable. The big reason comes down to adaptability: by minimizing the vendor-specific footprint, we maintain complete flexibility in changing these requirements in due course. In an ideal world the entire flow, both client and server, would be identical regardless of the technology stack used, but that doesn't reflect today's situation.

Our proposal is to start off with having vendor-specific authentication data in a single dictionary, used by any implementation which has that requirement, while keeping behavior for the rest of the front-end stack independent of the push technology used. Your proposal would result in having separate APIs and deriving behavior depending on the used push server, which requires authors to write different different code for each browser/push server combination. That may scale for browsers using GCM and APNS, but would lock out any vendor using a different system.

    * chrome.gcm exposes a MAX_MESSAGE_SIZE constant for exposing the maximum message size.

Given some of the differences between push servers, e.g. GCM supporting messages up to 4kb, APNS supporting messages up to 256 bytes, as well as giving the implementation a chance to update these limits whenever the push server's allowances change, this might be interesting to support.

One important thing to note here is that there various active discussions about how we (parties interested in bringing Push Messaging to the Web) should proceed with standardizing the client-side API. Mozilla's Jonas Sicking suggested a scenario in which each push server would implement a protocol-specific API, because pursuing standardization of the server-sided protocol has so far been considered out of scope. That seems to match your proposal.

I believe that a very good starting point would be a situation in which the client-side API is the same regardless of which push protocol is being used, minimizing the vendor-specific footprint. This would allow developers to use the exact same JavaScript code regardless of the push server used by the implementation. This gives us a lot of flexibility to improve *and* incentive on this situation in the future.

Without having both a standardized protocol and a shared sender registry, the vendor-specific sender information (sender Id for GCM, appKey for APNS) has to be provided on the client to meet requirements of all major push services. We're looking at possibilities for specifying the push server protocol, but this has many, many unsolved issues. Feel free to reach out directly if you'd like to know more :-).

    * The GCM API supports Google Cloud Messaging's upstream channel.

I understand that the primary benefit of upstream messaging is the guaranteed delivery, whereas an XHR may fail. Since we're already using Service Workers as the message delivery mechanism, it wouldn't be very hard for developers to enqueue the request to be retried later on.

Not sure what you mean by easy enqueue here... It is actually hard to properly save context and implement some sort of retry with backoff combined with network state tracking, and it also hard to do in battery-efficient way. But I guess I'm arguing the general point of Push API not benefiting from protocol-specific goodness.

There is work being done for doing background synchronization in a battery-efficient way as well, but that's orthogonal to the Push API. Service Workers are very appropriate tool for solving this kind of issue.

We'd like to lay the foundations first, and then iterate on additional features. GCM currently is one of the stronger featured push servers available, so it makes a lot of sense for us to drive future versions of the specifications.

Furthermore, as far as I'm aware, GCM is the only push service supporting an upstream channel. That would impose a barrier for other implementations (which may not be based on GCM) to fully support a specification. If we start discussing specifying the push service's protocol, this will definitely be an important area of focus. 

    * The GCM API requires the user to be logged in to Chrome in order to use the functionality.

The Push API will not require the user to be logged in to Chrome.

While current implementation of GCM API in Chrome indeed requires sign in, it is technically possible to remove this requirement. I believe the investigation and issues to resolve here are going to be the same as for current spec of Push API. Note Google account is not a requirement for GCM on Android starting 4.0.4...

 

To summarize, I don't agree that we're going "back to the beginning" with the client-sided API, since the two major differences are the absence of an upstream channel, and the (proposed) ability to only support a single sender Id. The addition of encryption is a very good thing, so that's something we'll definitely look into.

What about "do-not-collapse" messages? This is a queue-based mechanism to deliver a small data stream to the app, with a special marker (exposed in client API) delivered to app when queue overflows - useful for apps like PushBullet because it can make their servers much more stateless. Also, TTL support seems to be useful, especially for TTL=0 case, which is "deliver now or drop", I can see games use this. Knowing these details of service behavior can affect how client is coded up.

Both collapse_keys and time_to_live are features of the server-to-server protocol, which authors will still be able to specify and the GCM implementations (Google Play Services on Android, Chrome's own implementation elsewhere) will honor.

I agree that the implementation of client-side code can depend on whether or not these concepts work, but requiring all vendors interested in implementing this API to have push servers compatible with GCM will not only be highly controversial, but will significantly harm adoption of an API we believe is important in bridging a huge gap between native and the Web's capabilities. Starting off with a common foundation which addresses the important use-cases, and then iterating together towards a more feature-rich situation, is a much more constructive approach.

The story is more difficult on the server side, which is what I think you're getting at. The eventual goal of standardization would be to get rid of vendor-specific code throughout the entire path of a feature. While it would improve interoperability, specifying the server protocol would not solve that problem, because the second major vendor-specific extension is the addition of authentication information.

Developers being able to use identical code on the client is a big step towards solving the larger problem of having a single, unified path for pushing messages to any browser or device. 

Thanks,

Peter

Speaking about registration, the spec seems to imply that an app can create multiple registrations. It is not clear to me how this will be reflected on a sending side of gcm for example. While there are collapse keys that can be used to 'emulate' the multiple registrations, the number is limited and such mapping can be pretty confusing. Do you have a plan how you will implement this feature on top of GCM?

I am told that GCM on Android caches the registration Id, so that multiple registrations with the same sender Id would result in the same registration Id. I don't have an answer for that, but that's definitely something we'll have to look in to.

Overall, I think it's a great goal to make push services to agree on common standards, but how would it work in practice?  The services are much different and still actively developing. This is also being done by a crowd different from traditional browser developers, so it'll take longer to bridge viewpoints. In meanwhile, if there are just 2 "de-facto standards" (GCM and APNS), I can see value in providing those "as is" to web developers instead of introducing a 3rd, which is somewhat a subset of both and very likely will be significantly changed during standardization process. You seem to prefer to standardize client API w/o touching server-side story for now... but:

- single client API won't be congruent to server-side API of any service and this will be very confusing for developers

It is very likely that libraries will be created to bridge many of the differences. Advanced features such as collapse_keys and time_to_live are different because they're not supported by all push services, but then we get back to the multiple implementation question.

 

- current Push API based on version numbers does not have precedent in existing systems... No payload is hard limitation

The specification will be introducing a "data" property on the delivery side.

 

- it creates a new additional API for developers who likely already deal with most popular mobile push services.

Yes, but this will scale to desktop platforms and browsers as well, where there is a different balance between the actors.

Thanks,

Peter

[Dmitry Titov]

Thanks Peter.

I think I understand your approach now... If I may put it in my own words, it is to attempt implementation of a minimalistic API that can be implemented on top of current and future push services, potentially via a set of libraries on the server side and minimal irregularities like parameters for register() etc. It won't use many features available on 'native' services but hopefully will provide benefit of not having to code to several different services at least on the client. It is not an invalid idea, although the success of limited API obviously can be a thing to see. Whether the differences on server side can be helped by libraries is also unclear (those are not entirely APIs, but also actual servers configured in a specific way, managing keys, doing logging/monitoring etc). But I think the thread already captured this concern.

Speaking about proposed API in light of the 'minimalistic API' approach, I have some comments separate from the topics we already covered here:

1. The shape of the API looks like it's not quite service-independent. For example, multiple registrations do not map obviously into at least some existing services. It would be nice to have a plan on how to map features of the API to at least most popular known services. If the idea of that API is to be implemented on top of currently available services, I think the proposal to implement would be better with a doc attached explaining how it will be done on top of those services.

2. Some parts of API look like provision for some specific service, which is contrary to 'common API' idea. For example, pushEndpoints do not seem to apply to most of existing services. If they are in the spec for the benefit of some specific or hypothetical service, then maybe they shouldn't be there... Or the API is not really a 'common minimal' one.

3. Version numbers. We had them planned for GCM for Chrome v1 but removed before it shipped. The reason was that not a single developer we talked to had plan to use them. While an elegant idea, most apps either use something else (timestamp or some opaque 'continuation marker') and have no use for integers and don't generate them. Many apps do not support 'incremental fetch' at all (sports results can be fetched completely on every request) while others use app-specific markers and watermarks that are part of their request-response and they would only use the fact that they receive a push, as invalidation. Not clear why they should not be dropped from spec, especially if there is an intention to add a payload.

4. Even small custom payload is very valuable (and now looks like it can be done across major push systems). Developers may use it to indicate what changed or, sometimes, a url to fetch the updated data (if there can be multiple sources) or some other small pieces of metadata. Even if the channel is a collapsing one, this is often a very useful thing. I see you mentioned the spec is going to add 'data', this would be very useful for even initial implementation.

[rek...@gmail.com]

The link provided - https://code.google.com/p/chromium/issues/detail?id=349474 - is 403 Forbidden. I'd like some ability to track the port of Google Cloud Messaging into Chrome.

[rek...@gmail.com]

The previous ticket for W3 Push Api implementation- the one that's not currently 403 "Fuck You" Forbidden- is at https://code.google.com/p/chromium/issues/detail?id=348335 and I'd recently commented there that 439474 was 403 and that I'd like a live ticket to track.

[Dominic Cooney]

Profanity isn't appropriate here. "staying civil" sums up the situation.

[rek...@gmail.com]

The new link appears to be https://code.google.com/p/chromium/issues/detail?id=350378 .

I'll refocus my language. Might want to make the standards you are going to hold people to to be things people know to read, and can find. Perhaps a link on http://www.chromium.org/blink might help get that mission started?

My initial understanding was that the information was no longer available. I felt my consideration of the 403- in that regards- to be not completely inappropriate. Had the community provided any open guidelines I could read, I would have acted differently. As it stands, I feel my obligation is quite low.

[rek...@gmail.com]

It was quite a shock to me that the implementation of the Push service providing didn't use _any_ open standards, and that was not something I expected.

The reference to Firefox's implementation of Push API left me with the impression that Chrome would be open to various service providers, that there would be intercompatibility in a way that a website could use a common means across Chrome and Firefox to send a W3 Push API spec notification.

I'm not sure what the path is to use Push API as a web service provider: the future seems very uncertain, far more so than this Intent to Implement lead me to think it would be.  

[PhistucK]

You may want to read the intent to ship thread, it has more information about the standardization of push protocols.

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/UdGlL9PtBLo

☆PhistucK

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