Push API should be allowed without dependency on service worker about push-api HOT 10 CLOSED

Strongly disagree, for the reasons in http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0182.html

from push-api.

I also strongly disagree with this suggestion. The discussion on public-webapps captures exactly why this is unlikely to address web developer's needs, as they more complex and still evolving. It is a premature optimization.

from push-api.

Note though, that it's not a bad idea per se. It's a clear opportunity for optimization, but the form the optimization needs to take will not be clear until the lower level API gets significant usage.

from push-api.

Based on our conversations with Alex Russell [1], we can’t rely on a Service Workers being always available to process incoming push requests and notification clicks. The lifetime of a Service Worker is determined by the User Agent runtime. Based on our understanding the current Chrome implementation aggressively kills SW to reduce the tax on memory, CPU, and networking. Therefore, having a generic mechanism to handle the incoming requests is not just a performance optimization approach but required to ensure we handle incoming requests. In addition, we could push the same request to the SW if it is available.

[1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/QfxPGw0kJW8

from push-api.

we can’t rely on a Service Workers being always available to process incoming push requests and notification clicks.

There's been some misunderstanding about SW lifetime. Let me try to clarify the intention of the SW spec: SWs are normally stopped, and are started on demand to handle events like push, fetch, etc. Starting a SW is intended to be a cheap operation - when the JS file is executed*, authors should only register event handlers. Thus the SW is always able to handle incoming events, even if it wasn't yet running.

Once the SW has handled the event (which may include waiting for Promises passed to event.waitUntil - see #85), they will usually be killed again. In practice, UAs may keep them alive a little longer as a performance optimization (e.g. whilst a controlled page is loading, it's likely that there will be many fetch events due to subresource loads or XHRs, and it would be wasteful to start and stop the SW for each fetch), but authors should not rely on this (e.g. by storing globals).

*: (a smart VM might even be able to snapshot the state of the SW script after executing the JS file, then on subsequent startups simply restore that snapshot)

from push-api.

As discussed in the WG session at TPAC, I'm sharing the initial thinking on the interface.

partial interface PushRegistrationManager {
    Promise<PushRegistration>     register ( optional PushNotificationOptions options ); 
    PushNotificationOptions?      getPushNotificationOptions (); 
};

dictionary PushNotificationOptions {                       
    boolean systemNotificationEnabled = false;
    DOMString lang = "";                                      // BCP 47 language tag
    DOMString dir = "auto";                                   // "ltr", "rtl", "auto"
    DOMString sound = "";                                     // "auto", "ringtone", ""
};

As a reference, here is the link to the deck presented at TPAC.

from push-api.

I think there is consensus on the public-webapps mailing list [1], at TPAC [2], and in this repo, that maintaining a dependency on service workers is appropriate. It exposes the push functionality at a low and flexible level that is composable with other APIs and allows for common patterns to evolve. Google's Chrome team has also summarized their position on the pros and cons of an imperative vs a declarative approach in [3].

I think many people also agree that there is an opportunity for optimization by combining several APIs into one (a "declarative" API) that would avoid running a service worker in certain cases. However, specifying and implementing this would be a significant amount of work, and there is not currently a lot of agreement on what the feature set would be. It has been suggested to collect use cases, and performance data and requirements, that would inform such an effort. Potential spec dependencies of such an integrated higher level API are the Push API [4], the Notifications API [5], the Telephony API [6], and the WebRTC API [7].

As such, I'd like to leave this issue open but mark it as an enhancement for a future version of the Push API, or maybe as the basis for a separate spec that depends on the Push API.

[1] https://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0135.html
[2] http://www.w3.org/2014/10/27-webapps-minutes.html#item23
[3] https://docs.google.com/document/d/1kpTbKoPRaB4lXD6AMTCV2U5gTEPssQnqJj70KNb97SI/edit?usp=sharing
[4] https://w3c.github.io/push-api/
[5] https://notifications.spec.whatwg.org/
[6] http://sysapps.github.io/telephony/
[7] http://w3c.github.io/webrtc-pc/

from push-api.

I don't think that we can do this. @ShijunS, do you think that this is necessary still?

from push-api.

@martinthomson, We can close the issue and revisit the topic in the future if there is opportunity for optimization along the direction.

from push-api.

Thanks.

from push-api.