Re: Feedback on Quota Management API

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