Re: [whatwg] Notifications and service workers

On Thu, Sep 25, 2014 at 3:02 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Thu, Sep 25, 2014 at 2:28 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Wed, Sep 24, 2014 at 4:28 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>>> Strawman: We classify existing notifications as non-persistent
>>> notifications. Only notifications associated with a service worker are
>>> persistent.
>>
>> This is a little bit implicit for my taste. But I don't feel very strongly.
>
> I think it makes a lot of sense if we require service workers for
> persistent notifications. I figured we could rename the field from
> serviceWorker to something more explicit, but I can't really think of
> a good name.


I was thinking of something more along the lines of using different
constructors for persistent vs. non-persistent notifications. But like
I said, I don't feel strongly.

Or, should persistent notifications not use a constructor at all?
What's the purpose of having a reference to a Notification object if
no events will ever fire on it? Maybe we should have a function like

promise = createPersistentNotification(...);
promise.then(notificationWasShown, notificationWasRejected);

> That means we should tie normal non-persistent notifications to the
> lifetime of the global. I take it we still want to allow those within
> workers, right?

If we tie non-persistent notifications to the lifetime of a global,
then I don't know that it makes sense to allow them to be created from
a worker.

But maybe a better model is to define that non-persistent
notifications are shown for a small period of time. That's how they
seem to be implemented on existing OSs. OSX shows notifications for a
few seconds, then they go away.

>> But maybe they are rare enough that by default we only fire "click"
>> events. For persistent notifications we fire them at the SW, for
>> non-persistent at the Notification object.
>>
>> If we in the future find actual use cases for "close"/"show" we can
>> add ways to opt in to receiving those. And if we find use cases for
>> *not* receiving "click" (in particular to SW) we can add ways to opt
>> out of those.
>
> This strategy makes sense to me. If Jake and Peter (and everyone else
> who feels inclined :-)) could comment on this revised proposal that'd
> be great.

Having thought about this some more, I think it would create a very
messy API if we end up with

new Notification("Hello world", {
  body: ...,
  dontFireClick: true,
  requestExtraEvents: ["show", "close"]
});

Generally speaking, starting a SW is a fairly expensive operation. So
I think it's good if APIs that hook into SW allow the author to be
explicit about what events they care about receiving.

OTOH, if we really can't think of any use cases for show/close events,
then it seems silly to require that every single caller specifies that
it wants to receive click and nothing else.

/ Jonas

Received on Thursday, 25 September 2014 22:48:59 UTC