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

Re: Feedback on Quota Management API

From: Tobie Langel <tobie@fb.com>
Date: Wed, 30 May 2012 16:54:53 +0000
To: Kinuko Yasuda <kinuko@chromium.org>
CC: Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>, Eric Uhrhane <ericu@chromium.org>
Message-ID: <CBEC1BC4.83C76%tobie@fb.com>

On 5/30/12 6:30 PM, "Kinuko Yasuda" <kinuko@chromium.org> wrote:

>Thanks for the feedback!
>On Tue, May 29, 2012 at 11:07 PM, Tobie Langel <tobie@fb.com> wrote:
>On 5/17/12 11:02 AM, "Kinuko Yasuda" <kinuko@chromium.org> wrote:
>>For context for others, I assume they are comments for the draft pushed
>I'm super excited to see an API for this is in the works. It's been a much
>wanted feature by developers.
>Couple of thoughts/questions (sorry for the late feedback, I was on
>parental leave):
>1. My experience with measuring maximum storage quota in existing
>implementations shows that while some implementations share a common quota
>across different data stores (e.g. 10 MB for both localStorage and
>AppCache on iOS last time I looked), not all do. What's the reasoning
>behind enforcing this (is it easier for implementors? Better for
>developers?) and is there agreement across implementors that this is the
>way forward?
>I believe this is for developers and users.  (I don't think this would
>it easier for implementors)
>Today we have multiple API options to store data locally, but most users
>wouldn't care which API an app is using.  They might be interested in
>"how much data is stored by an app" or "why my disk is getting tighter",
>but wouldn't be interested in "I'm ok with API X storing B bytes, but
>not for API Y".  Similarly I can imagine developers would care about
>how much more they can store for their app, but they wouldn't want to
>care about multiple quota values for each API.  Overtime they
>may want to switch storage APIs, but if the switch requires quota
>adjustment across storage that sounds very awkward.
>This idea has been discussed several times on this list before, and
>in my belief there's some consensus we want to have a single quota
>across different storages (some pointers from past discussion: [1][2]).

Makes sense and thanks for the pointers.

>2. If the case is that we're going for a binary choice (i.e. persistent
>vs. temp data stores) why not create specific methods for each rather than
>pass a constant (or string) as first argument: e.g.:
>    navigator.storageInfo.queryTemporaryUsageAndQuota
>    navigator.storageInfo.queryPersistentUsageAndQuota
>That'll avoid having to deal with typos in the first arg, error handling
>in that case, etc.
>I haven't thought about this before, nor have a strong opinion on this,
>but I remember that in the past someone has commented that only two
>storage types might not be enough.  I don't think we want more storage
>types right now, but keeping it as enum or constant would make it easier
>to add more storage types in a future.  What do you think?

I can't think of a storage type (or anything else, for that matter) that
would be neither persistent nor temporary.

Also: http://robert.ocallahan.org/2012/05/canvas-getcontext-mistake.html

Received on Wednesday, 30 May 2012 16:55:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:34 UTC