Makes sense, ok let's keep it. Then we will have symmetric four methods,
request and query for each type.
On Jun 1, 2012 6:17 PM, "Tobie Langel" <tobie@fb.com> wrote:
> 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 10:08:17 UTC