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" <to...@fb.com> wrote:
> On 6/1/12 10:34 AM, "Kinuko Yasuda" <kin...@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 > >