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

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