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

Re: Feedback on Quota Management API

From: Eric Uhrhane <ericu@chromium.org>
Date: Wed, 30 May 2012 11:05:41 -0700
Message-ID: <CAHvSExcMFvF5N2Zv-BAP4vGkKcdHCBngJf-t+P0wseex4pOacA@mail.gmail.com>
To: Tobie Langel <tobie@fb.com>
Cc: Kinuko Yasuda <kinuko@chromium.org>, Anne van Kesteren <annevk@annevk.nl>, WebApps WG <public-webapps@w3.org>
On Wed, May 30, 2012 at 9:54 AM, Tobie Langel <tobie@fb.com> wrote:
> 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.

How about "session", which is guaranteed to go away when the browser
exits, "document-local" which isn't shared by other documents in the
same domain, "window-local", which isn't shared by other windows...I'm
sure there are more.  Let's not box ourselves in.

> Also: http://robert.ocallahan.org/2012/05/canvas-getcontext-mistake.html
> --tobie
Received on Wednesday, 30 May 2012 18:06:29 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:40 UTC