- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 14 Oct 2013 15:09:58 +0100
- To: James Burke <jrburke@gmail.com>
- Cc: WHATWG <whatwg@lists.whatwg.org>
On Fri, Sep 27, 2013 at 2:15 AM, James Burke <jrburke@gmail.com> wrote: > 1) Ability to pass data with the Notification > > Right now, we URL-encode some args to the iconURL to pass data to the > handler function that is registered via > navigator.mozSetMessageHandler('notification', function(){}) [1]. > > It would be better if I could just pass a JSON-friendly data object to > Notification instance and then have access to that data in the > notification callbacks that are triggered. > > We cannot depend on notification.onclick to work since the app can be > closed after the notification is fired. It also seemed very unreliable > to depend on it, given garbage collection possibilities. So we cannot > reliably capture state using a function closure. I pointed this out in: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Aug/0337.html 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? 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). Making this non-observable in a world where structured cloning might become extensible seems tricky. -- http://annevankesteren.nl/
Received on Monday, 14 October 2013 14:10:29 UTC