Re: Feedback on Quota Management API

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
>>at:
>>https://dvcs.w3.org/hg/quota/Overview.html
>
>
>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
>make
>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]).
>
>[1] 
>http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0400.html
>[2] 
>http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0357.html

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

--tobie

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