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