W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2014

Re: [whatwg] Notifications and service workers

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 25 Sep 2014 21:30:17 +0200
Message-ID: <CADnb78i1MmeaL8R=n192N_ydAn07HjfTrvh54SYsL77HD=Ay3g@mail.gmail.com>
To: Jake Archibald <jaffathecake@gmail.com>
Cc: WHATWG <whatwg@whatwg.org>, Jonas Sicking <jonas@sicking.cc>, Peter Beverloo <beverloo@google.com>
On Thu, Sep 25, 2014 at 12:25 PM, Jake Archibald <jaffathecake@gmail.com> wrote:
> Totally agree, I didn't realise this was possible in the original proposal.
> The option that makes it a persistent notification should retarget all
> events to the serviceworker. If the serviceworker is invalid, I guess we
> throw?

Yup.


> eventTarget: serviceWorkerRegistration
>
> persistWith: serviceWorkerRegistration

Hmm, serviceWorker still seems best.


> The ServiceWorker default would be persistent though right? Creating a
> non-persistant notification in a ServiceWorker is likely to go wrong as you
> lose your event handers when the worker terminates.

Yeah, for service workers the default would be a persistent one. I was
thinking we could allow an explicit

  serviceWorker: null

to override that, but I'm not sure it buys us much. The lifetime of
non-persistent notifications would be the lifetime of the global they
are created in (or presumably lifetime of the active document in case
of a document environment).


> I don't have a use-case for "show" right now, but I think we need to keep
> "close" for the use-case above. An events property could take an array to
> restrict the events a notification will fire (defaulting to all).

That would work too. Not sure I have a good sense of what would be best here.


-- 
https://annevankesteren.nl/
Received on Thursday, 25 September 2014 19:30:46 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:23 UTC