- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 26 Sep 2014 09:09:48 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: WHATWG <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Peter Beverloo <beverloo@google.com>
On Fri, Sep 26, 2014 at 6:40 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Fri, Sep 26, 2014 at 3:31 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> On Fri, Sep 26, 2014 at 6:23 AM, Anne van Kesteren <annevk@annevk.nl> wrote: >>> On Fri, Sep 26, 2014 at 12:48 AM, Jonas Sicking <jonas@sicking.cc> wrote: >>>> promise = createPersistentNotification(...); >>>> promise.then(notificationWasShown, notificationWasRejected); >>> >>> Well presumably we still want to share an object of sorts as part of >>> the event, so all the notification data is exposed somehow. A promise >>> does not make much sense to me as a service worker can be killed at >>> any point. >> >> I'm not sure I understand what you are saying here. The above code is >> the creation steps, not the notification steps. > > Oh, but shown implies it's displayed, which currently can happen > later. But as per the other thread maybe we should get rid of that. > Assuming we get rid of that, this seems to help a bit with error > handling, but is otherwise mostly identical in approach to just > keeping the constructor. It's a good point that if the above call happens in a SW, then there's no guarantee that it'll receive either of those callbacks. So it comes down to if we need "show", and I guess "error", events. One option that I could think of is that Windows that create a notification could detect if the notification fails to be displayed, and if so display in-page UI. Either to replace the notification, or to indicate to the user that notifications currently don't work. In this case the above API could work since a SW can't display such UI anyway, and so it doesn't matter that it might not receive the promise callbacks. / Jonas
Received on Friday, 26 September 2014 16:22:56 UTC