- From: Tobie Langel <tobie@fb.com>
- Date: Tue, 11 Sep 2012 09:50:41 +0000
- To: Kinuko Yasuda <kinuko@chromium.org>
- CC: "public-webapps@w3.org" <public-webapps@w3.org>, Jonas Sicking <jonas@sicking.cc>, Eric Uhrhane <ericu@chromium.org>
On 9/11/12 10:57 AM, "Kinuko Yasuda" <kinuko@chromium.org> wrote: >Hi Tobie, >Session storage type or some storage options which can be explicitly >'expired' sounds useful. >Through some offline local discussion I've been thinking that having some >configurable 'expire' option in Temporary or in a new storage type might >be useful in various situations. > >On Mon, Sep 10, 2012 at 6:40 PM, Tobie Langel <tobie@fb.com> wrote: > > >Hi all, > >Following a recent conversation with Jonas (and contrary to what I >initially claimed here) there's value in adding a third storage type to >the Quota API: Session storage. > >Contrary to temporary storage which might not get wiped across UA >sessions, Session storage MUST get wiped when the session is closed. > >Let me bring the same questions when the same/similar storage type is >mentioned in the past thread: should it go away in an unexpected crash? >And/or should it be persisted if the UA restores the session when it >restarts? I think it should follow the behavior of session cookies, for consistency. >Or does it make sense if we redefine/extend the Temporary storage type to >allow the user to specify some explicit expire option, like >expire-on-session-close or expire-after-this-time? Though in this >approach we cannot use more than one expire option at a time in one UA. That's certainly possible today already but is out of the scope of the spec. >Slightly tangent: >A related question is how the new storage type should be enforced on >various storage APIs. No storage APIs other than FileSystem API has an >explicit way to associate their data/storage to a particular storage >type, and the current FileSystem API only knows temporary and persistent >types. Well, there's the distinction between localStorage and sessionStorage to keep in mind. (Not sure whether the former falls under temp or persistent, however). >If we're adding more storage types (with different expire options) it >might be nice to have a better unified way to associate a group of data >items/units to a specific storage type/options across different storage >APIs. That's an interesting suggestion. It's implicit when choosing sessionStorage (session) or AppCache (temp) but unclear for IDB and localStorage. Maybe a standard API for this would be a good thing. --tobie
Received on Tuesday, 11 September 2012 09:51:04 UTC