Re: Feedback on Quota Management API

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

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?


Best,
>
> --tobie
>
>