Re: Quota API to query/request quota for offline storages (e.g. IndexedDB, FileSystem)

On Thu, Feb 3, 2011 at 2:25 AM, Kinuko Yasuda <kinuko@chromium.org> wrote:
> Hi,
>
> Back then there has been a long thread [1] about how/whether we want to
> allow web apps to request quotas for IndexedDB, or for any of the offline
> storages (i.e. IndexedDB, FileSystem, appCache, localStorage and SQL DB).
> In short there were two topics discussed:
>
>   1) introducing (at least) two different storage categories,
>   "temporary/evictable/transient" and "persistent/non-evictable".
>
>   2) introducing a new app-facing API to request or query quota/usage.
>   There were basically two API proposals, one is to "request more
>   (persistent) storage quota" and the other is to "query the current
>   quota and used amount".
>
> As for 1) we seem to have roughly agreed on this. FileSystem API and
> IndexedDB [2] are in that direction, and it was also discussed that
> probably we could add "Persistent" storage option to other APIs. [3]
>
> As for 2) we haven't had a concensus yet, but It sounds beneficial
> for both webapps and UA to allow an app to request quotas up front,
> as with the API neither webapps nor UA need to worry about quota
> error/notification handling in the middle of storage operations.
> Also we hear a lot of developers wanting to know "how much storage
> our app can use?" information up front to make their apps more
> usable with some storage constraints.
>
> To reopen the quota API discussion, I'd like to propose following
> asynchronous API that works across all the offline storage APIs:
>
>   interface StorageInfo {
>    // storage type
>     const unsigned short TEMPORARY = 0;
>     const unsigned short PERSISTENT = 1;
>
>     // To query how much storage is available and currently in use.
>     void queryUsage(unsigned short storageType,
>                     UsageCallback usageCallback);
>
>    // To request a new quota size.
>     void requestQuota(unsigned short storageType,
>                       unsigned long long newOriginQuotaInBytes,
>                       QuotaCallback quotaCallback);
>   };
>
>   interface UsageCallback {
>     void handleEvent(unsigned long long currentOriginUsageInBytes,
>                      unsigned long long currentOriginQuotaInBytes);
>   };
>
>   interface QuotaCallback {
>     void handleEvent(unsigned long long grantedOriginQuotaInBytes);
>   };
>
>
> With this API I assume multiple offline storage APIs share the same
> single (persistent) quota and usage info per origin, but that detail
> could be probably left up to UA.
>
> Thanks in advance for any feedbacks/comments.
>
> [1] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/thread.html#msg102
> [2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=11350
> [3] http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0253.html

This seems to straddle the line between simplicity and usefulness
pretty well. Definitely agree that we want to treat this as a single
quota rather than trying to separate quota for the various storage
mechanisms.

One thing that you are not discussing is UA behavior when the quota
limit is reached. In Firefox 4, for IndexedDB, once the page reaches
50MB, we prompt the user if he/she wants to allow the page to store
more information. Only if the user chooses "no" do we start failing
writes. If the user chooses "yes" the fact that we reached the quota
limit is transparent to the page (apart from that a write takes a bit
longer while waiting for the prompt).

Technically we don't need to change anything about the spec to handle
this, we can just allow the UA to increase the quota limit at any
point in time if it desires. But I figured I should bring it up.

/ Jonas

Received on Thursday, 3 February 2011 20:53:02 UTC