- From: Tobie Langel <tobie@fb.com>
- Date: Fri, 1 Jun 2012 09:17:28 +0000
- To: Kinuko Yasuda <kinuko@chromium.org>
- CC: Eric U <ericu@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, "public-webapps@w3.org" <public-webapps@w3.org>
On 6/1/12 10:34 AM, "Kinuko Yasuda" <kinuko@chromium.org> wrote:
>If we go along the line we will have four methods on StorageInfo:
>
>queryPersistentUsageAndQuota
>queryTemporaryUsageAndQuota
>requestPersistentQuota
>
>We could also think of 'requestTemporaryQuota', a variant of
>requestQuota, but by the nature of temporary storage UA will not
>secure/reserve space for temporary storage and I don't think requesting
>quota for temporary storage makes a good sense. (Objections welcome, we
>could also leave it to UA and allowing it to return unsupported error)
The fact that a UA can expire temporary data when it detects it has
limited storage space is orthogonal to the amount of said storage the
author might want to have access to. And given temporary data is capped
the same way persistent data is, there needs to be an equivalent API to
request its augmentation. Your draft spec already caters for the case
where not enough space would be available ("successCallback may return a
smaller amount of quota than requested."), so I don't think that's a
concern. It's also much better in terms of API consistency.
--tobie
Received on Friday, 1 June 2012 09:20:21 UTC