- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Tue, 23 Sep 2014 15:31:07 +0200
- To: WHATWG <whatwg@whatwg.org>
- Cc: Jake Archibald <jaffathecake@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Peter Beverloo <beverloo@google.com>
Peter and Jake made a proposal for notifications and service workers, but I believe Jonas wanted something without events. I'll outline the proposal from Peter and Jake below. Hopefully we can then discuss on how to move this forward. We add "serviceWorker" to Notification and NotificationOptions. When a Notification is constructed within a service worker it is set automatically, in other environments it needs to be set to a ServiceWorkerRegistration object (allowing it to be overridden inside a service worker is probably okay). (If there's an issue with the ServiceWorkerRegistration object we throw.) If this succeeds, the underlying notification is associated with a service worker. If a notification is associated with a service worker, events are dispatched to the service worker, rather than to Notification objects associated with the notification. These events also expose a new Notification object (cloning is cheap). Suggestions I remember: * Expose promises on Notification objects to see whether a notification has been clicked or closed. (And keep track of such state somewhere.) * Dispatch events to Notification objects as well even if the notification has an associated service worker. Requiring message channel roundtrips for this is cumbersome. This is also tracked on GitHub: https://github.com/whatwg/notifications/issues/19 -- https://annevankesteren.nl/
Received on Tuesday, 23 September 2014 13:31:36 UTC