W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2013

Re: [whatwg] Notifications: usage feedback

From: James Burke <jrburke@gmail.com>
Date: Wed, 16 Oct 2013 13:22:15 -0700
Message-ID: <CAHgY_ifyQtTh2zTonHTduRajSnnm8wKyYGPjVxgTC3w41rjaxQ@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WHATWG <whatwg@lists.whatwg.org>
On Mon, Oct 14, 2013 at 7:09 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>
> It seems using a structured clone makes the most sense. Transfering
> objects won't work here. It's not entirely clear to me what the best
> is for Blob, File, etc. Effectively the page can shut down, but they
> will still be kept alive through this Notification. I guess it's not
> too different from what Indexed DB can do.
>
> Is what what we want?

For my purposes, I was fine limiting to "JSON-serializable", as that
is basically what I got with the iconURL hack we use now. However it
is likely that you have a better idea of what makes sense across the
platform.

For the email use case for notifications, we expect the app to be
completely removed from memory every so often, so we just want to
store enough simple state to route the action to take for the
notification correctly. The data in that case is more like a GET
querystring.

> My proposal would be to add a data member to NotificationsOptions and
> a data property to Notification objects. The constructor does a
> structured clone so that the data property returns a fresh object and
> its established the object can indeed be cloned. I guess we'd also
> have to keep a copy alive somewhere in case we need to create a new
> instance of the Notification object (e.g. when Notification.get() is
> used).

Those API changes work for me.

James
Received on Wednesday, 16 October 2013 20:22:40 UTC

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