- From: Tobie Langel <tobie@fb.com>
- Date: Wed, 30 May 2012 19:50:06 +0000
- To: Eric U <ericu@google.com>, Boris Zbarsky <bzbarsky@mit.edu>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>
On 5/30/12 9:03 PM, "Eric U" <ericu@google.com> wrote: >On Wed, May 30, 2012 at 11:59 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: >> On 5/30/12 2:05 PM, Eric Uhrhane wrote: >>> >>> How about "session", which is guaranteed to go away when the browser >>> exits >> >> >> Should it go away if the browser crashes (or is killed by an OOM killer >>or >> the background process killer on something like Android) and then >>restarts >> and restores the session? >> >> Should it go away if the user has explicitly set the browser to restore >> sessions and then restarts it? > >Off the top of my head, I dunno. I was just giving examples to >explain that "I can't think of any other storage types" isn't a very >solid argument that there will never be any more. I'm not actually >proposing that we implement any of these at this time. Agreed, that's orthogonal. I was trying to make two points. The first, pedantic, that the union of persistent and temporary storage was the universe and thus that all future data stores would fit in either one of those (e.g. Session goes in temporary, document-local would necessarily have to be one or the other (or in both), etc.). The second, that avoiding the first parameter would make the API more readable, more "weby", more robust, and still as extensible (nothing prevents adding a `navigator.storageInfo.querySessionUsageAndQuota` property). >Also, having read Robert's blog post now, I think he makes some good >points, especially w.r.t. feature detection. Yeah, that was a timely finding, bumped into it minutes after my first email. --tobie
Received on Wednesday, 30 May 2012 19:50:34 UTC