W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

Re: [quota-api] Need for session storage type

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>
Message-ID: <CC74D481.25ABC%tobie@fb.com>
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

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

>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

Well, there's the distinction between localStorage and sessionStorage to
keep in mind. (Not sure whether the former falls under temp or persistent,

>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

That's an interesting suggestion. It's implicit when choosing
sessionStorage (session) or AppCache (temp) but unclear for IDB and

Maybe a standard API for this would be a good thing.

Received on Tuesday, 11 September 2012 09:51:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 14:37:00 UTC