- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 29 Oct 2013 08:43:57 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: WHATWG <whatwg@lists.whatwg.org>, James Burke <jrburke@gmail.com>
On Tue, Oct 29, 2013 at 7:32 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Wed, Oct 16, 2013 at 9:22 PM, James Burke <jrburke@gmail.com> wrote: >> 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. > > Okay, so maybe we should simply store a JavaScript string instead? No > need to play with structured clones if something simple is sufficient > I suppose. Strings certainly solves the use cases since anything can be encoded into a string. However it seems to me that using structured clones will make things a lot easier for pages in many cases. This was always *the* top complaint about localStorage from authors. Either way we probably need to put some limit on how much data you can store. / Jonas
Received on Tuesday, 29 October 2013 15:44:56 UTC