W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: Feedback on Quota Management API

From: Kinuko Yasuda <kinuko@chromium.org>
Date: Fri, 1 Jun 2012 17:34:43 +0900
Message-ID: <CAMWgRNa6Suvut+54XuxOehjjzwOdW7a7iWm4cu75eJT+4i3ROA@mail.gmail.com>
To: Tobie Langel <tobie@fb.com>
Cc: Eric U <ericu@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, "public-webapps@w3.org" <public-webapps@w3.org>
On Thu, May 31, 2012 at 4:50 AM, Tobie Langel <tobie@fb.com> wrote:

> On 5/30/12 9:03 PM, "Eric U" <ericu@google.com> wrote:
>
> >On Wed, May 30, 2012 at 11:59 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> >> On 5/30/12 2:05 PM, Eric Uhrhane wrote:
> >>>
> >>> How about "session", which is guaranteed to go away when the browser
> >>> exits
> >>
> >>
> >> Should it go away if the browser crashes (or is killed by an OOM killer
> >>or
> >> the background process killer on something like Android) and then
> >>restarts
> >> and restores the session?
> >>
> >> Should it go away if the user has explicitly set the browser to restore
> >> sessions and then restarts it?
> >
> >Off the top of my head, I dunno.  I was just giving examples to
> >explain that "I can't think of any other storage types" isn't a very
> >solid argument that there will never be any more.  I'm not actually
> >proposing that we implement any of these at this time.
>
> Agreed, that's orthogonal.
>
> I was trying to make two points. The first, pedantic, that the union of
> persistent and temporary storage was the universe and thus that all future
> data stores would fit in either one of those (e.g. Session goes in
> temporary, document-local would necessarily have to be one or the other
> (or in both), etc.). The second, that avoiding the first parameter would
> make the API more readable, more "weby", more robust, and still as
> extensible (nothing prevents adding a
> `navigator.storageInfo.querySessionUsageAndQuota` property).


Ok I'm getting convinced as well.  Session storage is an interesting
possibility but that sounds like a variant of temporary storage.  I also
agree that we could still add a new method if we really need it, and it
could help developers especially regarding feature detection.

If we go along the line we will have four methods on StorageInfo:

queryPersistentUsageAndQuota
queryTemporaryUsageAndQuota
requestPersistentQuota

We could also think of 'requestTemporaryQuota', a variant of requestQuota,
but by the nature of temporary storage UA will not secure/reserve space for
temporary storage and I don't think requesting quota for temporary storage
makes a good sense.  (Objections welcome, we could also leave it to UA and
allowing it to return unsupported error)

If this looks good to the people on this list I'm going to make the change
in the draft.


 >Also, having read Robert's blog post now, I think he makes some good
> >points, especially w.r.t. feature detection.
>
> Yeah, that was a timely finding, bumped into it minutes after my first
> email.
>
> --tobie
>
>
>
Received on Friday, 1 June 2012 08:35:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:52 GMT