- From: James Burke <jrburke@gmail.com>
- Date: Wed, 16 Oct 2013 13:22:15 -0700
- 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