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

On Tue, Oct 30, 2012 at 1:04 PM, Brady Eidson <beidson@apple.com> wrote:
> (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.

Not true--databases do this all the time, as do journaling
filesystems.  While it's hard to guarantee that e.g. all data is wiped
from the system, you can certainly specify whether or not it should be
accessible to script on the next page load after the crash.

I think the bigger question is "What's a session"?
Does it end if I:

	* close the window?
	* close the last window in this origin?
	* close the last window in this browser profile?
	* quit the browser?
		- With or without "continue where I left off"/"load my same windows
from last time"?
		- Due to an update that caused a restart?
		- Due to a crash, with automatic crash recovery?
	* switch to another app on my phone/tablet?
	* use enough other apps on my phone/tablet that the browser gets
purged from memory?

I doubt browsers are consistent in all these situations, given that
current Chrome doesn't behave the same as the Chrome of a year ago.
So saying "it should act like session cookies" doesn't work.

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

Received on Wednesday, 31 October 2012 17:04:18 UTC