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

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?

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.

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.

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.


Happy to provide patch if there's agreement this is a valuable addition to
> the spec.
>
> Best,
>
> --tobie
>
>