[whatwg] Notifications: usage feedback

James Burke jrburke at gmail.com
Wed Oct 16 13:22:15 PDT 2013

On Mon, Oct 14, 2013 at 7:09 AM, Anne van Kesteren <annevk at 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

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

> 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.


More information about the whatwg mailing list