W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2013

Re: Updating Quota API: Promise, Events and some more

From: Kinuko Yasuda <kinuko@chromium.org>
Date: Tue, 27 Aug 2013 11:40:20 +0900
Message-ID: <CAMWgRNbJFtDSchhFQEdZ0=ESztpf+2xYaocc3xvfdVoG=CPrzA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Alex Russell <slightlyoff@google.com>, Ehsan Akhgari <eakhgari@mozilla.com>, Nikhil Marathe <nmarathe@mozilla.com>, Joshua Bell <jsbell@chromium.org>, Webapps WG <public-webapps@w3.org>
On Tue, Aug 27, 2013 at 4:26 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> Thanks, that explains the concern.
> However the proposed solution doesn't seem to solve the problem
> particularly well, for two reasons:
> First off, an API which lets the website track how much data it is
> storing, measured in bytes, doesn't seem like it solves the problem.
> You also need to track quota as it is shrinking. Otherwise you won't
> know when you are starting to butt up against the quota limit which
> might cause you to get evicted more quickly. This also indicates that
> setting limits in bytes, and getting notified when you cross those
> limits, is the wrong API, since the limit would have to be adjusted
> any time the available quota shrinks.
> The second problem is harder to address. The problem is that the used
> quota could go down even when the website isn't open. We'd need
> something like event pages, and an event fired at those, to tackle
> this problem.

I believe the first problem can be addressed by polishing API details,
but I have to agree that the second problem would be much better
addressed in conjunction with event pages, and it might be
better to wait until it matures.

Unfortunately event pages, and how to fire events at them, is
> something that's still being developed. Which makes it hard to know
> what this API should look like. Until we have that figured out, maybe
> something like this would be ok to put in the draft:
> [Constructor(StorageType type, unsigned long rate)]
> interface StorageWatcher {
>   readonly attribute StorageType type;
>   readonly attribute unsigned long rate;
>   attribute EventHandler onstoragechange;
>   attribute EventHandler onquotachange;
> };

I'm sold! Also I think in this way having only
onstoragechange would be enough to start with.

Let me summarize what came out so far:

  enum StorageType { "temporary", "persistent" };

  partial interface Navigator {
    readonly attribute StorageQuota storageQuota;

  [NoInterfaceObject] interface StorageInfo {
    unsigned long long usage;
    unsigned long long quota;

  [NoInterfaceObject] interface StorageQuota {
    readonly attribute StorageType[] supportedTypes;

    // Queries the current storage info.
    Promise<StorageInfo> getInfo(StorageType type);

    // Requests a new quota for persistent storage.
    Promise<StorageInfo> requestPersistentQuota(unsigned long long

  [Constructor(StorageType type, unsigned long rate)]
  interface StorageWatcher : EventTarget {
    readonly attribute StorageType type;
    readonly attribute unsigned long rate;

    attribute EventHandler onstoragechange;

  interface StorageEvent : Event {
    readonly attribute unsigned long long usage;
    readonly attribute unsigned long long quota;

Thanks for all the discussion so far.
I'll repost on public-webapps when I update the draft.
(Would it be better to send the draft to public-script-coord too?)

(And as always more feedback / comments are always welcome)


/ Jonas
Received on Tuesday, 27 August 2013 02:41:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:12 UTC