W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: Feedback on Quota Management API

From: Kinuko Yasuda <kinuko@chromium.org>
Date: Fri, 1 Jun 2012 19:07:38 +0900
Message-ID: <CAMWgRNbt5vyjvC4YrMSV7HCaODMwh9JEV1XYoCRBAm+khM=f0A@mail.gmail.com>
To: Tobie Langel <tobie@fb.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Web Applications Working Group WG <public-webapps@w3.org>, Eric U <ericu@google.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:34 UTC