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

Reviving this thread as well... to give a chance to get more feedbacks
before moving this forward.

Let me briefly summarize:
The proposal was to add 'Session' storage type to the quota API, whose data
should get wiped when the session is closed.

Past related discussion:
* Should the data go away in an unexpected crash?
  --> It should follow the behavior of session cookies on the UA
* Some storage APIs implicitly have default storage types (e.g.
sessionStorage -> session, AppCache -> temp) but IDB and localStorage do
not have them. If we have more storage types we might need an explicit way
to associate a storage API (or a data unit) to a particular storage type.
  --> would be nice, we'll need a separate proposal / design for this though

The idea sounds useful, but I may want to hear a bit more discussion /
opinion from other developers / vendors.

On Tue, Sep 11, 2012 at 6:50 PM, Tobie Langel <tobie@fb.com> wrote:

> 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
>
>