- From: Eric Uhrhane <ericu@chromium.org>
- Date: Wed, 30 May 2012 11:05:41 -0700
- 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 >>>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. 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