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

(Sending again as my first attempt seems to have not gone out to the list)

On Oct 30, 2012, at 12:10 PM, Kinuko Yasuda <kinuko@chromium.org> wrote:

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

I like this.

> Past related discussion:
> * Should the data go away in an unexpected crash?
>   --> It should follow the behavior of session cookies on the UA

I'm not sure how useful it is to specify behavior in an unexpected crash.  Almost by definition, such an event cannot have defined behavior.

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

This is an especially squirrely area.

Even the assumed default storage types listed are not necessarily accurate.  For example, WebKit supports making AppCache permanent and that is supported on Mac and iOS.

How we should define which technology belongs to which storage type is not obvious to me.  It requires explicitly specifying a storage type for each existing and future storage technology.  It requires that storage type being a "must" requirement for each of those specs.  And that removes the ability for user agents to be flexible in managing their own storage.

For example, today a user agent could implement AppCache as permanent… up to a limit… at which point the application could go over that limit but now only be temporary.

We would either have to remove that flexibility or account for it in this API.

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

This is another example of the particularly squirrely area I mention above.

As the LocalStorage spec reads today, any attempted guarantees as to the lifetime of the data are "should" level guarantees and therefore not guarantees at all.  Therefore it is inarguably specified as a "temporary" storage.

However, Apple treats LocalStorage as sacred as a file on the filesystem and we've reiterated our position on this in discussions in the past.  WIll we have to report this in navigator.temporaryStorage anyways?

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

I think we have to fully resolve this to move forward.

Thanks,
~Brady