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

On Mon, Aug 26, 2013 at 1:39 AM, Kinuko Yasuda <kinuko@chromium.org> wrote:
>
> Going back to the use case 2, let me try to explain a sample scenario:
>
> Let's say website A has stored some data in temporary storage. The amount of
> data was less than the per-site quota at the time (otherwise the write must
> have failed), since there was lot of available space.  But then the
> remaining disk space has gotten smaller, and Chrome realizes that it needs
> to make some more space.  If website A has done nothing until then Chrome
> will eventually evict site A (before or after evicting other sites), but if
> it could have told A that its remaining storage was less than before or was
> getting over-budget, A might have been able to react the events and to
> reduce some data so that Chrome may not need to evict any data.  This
> scenario is over-simplified and when there're multiple websites just one
> site reducing its data may not do any favor to the site (except that the
> LRU-policy will implicitly help the site's data stay longer than others),
> but in general if the site is constantly being used/opened and keeps being a
> good citizen in terms of storage usage, the site would have much less
> possibility to be evicted.  Does it make sense to you?

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.

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;
};

/ Jonas

Received on Monday, 26 August 2013 19:27:00 UTC