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

On Sat, Aug 24, 2013 at 3:45 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Aug 23, 2013 12:30 AM, "Kinuko Yasuda" <kinuko@chromium.org> wrote:
> > On Tue, Aug 20, 2013 at 1:49 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> >>
> >> On Mon, Aug 19, 2013 at 9:32 AM, Kinuko Yasuda <kinuko@chromium.org>
> wrote:
> >> >> Actually, *only* having onstoragechange would solve both the use case
> >> >> of detecting when you are running low on storage, as well as when you
> >> >> are "out of the woods". Especially if we provide both the quota and
> >> >> the amount of used space in the event.
> >> >
> >> > Right.  I think probably we should add either "a combination of
> >> > storagelow + storageok" or "storagechange", and the latter would be
> >> > more complete (and possibly be simpler).
> >> >
> >> > One concern for adding storagechange event is how frequently
> >> > the event is going to be fired.  In the former email I tentatively
> wrote
> >> > this to be fired every 1 second at most frequent (or whenever the
> >> > storage info is changed), but this may be still too frequent if many
> >> > apps are contending to a storage space.  Do you have any opinion
> >> > or preference on this?
> >>
> >> I think firing every second while writes are happening would actually
> >> be ok. Seems like you are spending a lot of battery power anyway at
> >> that point and so an extra callback a second doesn't seem like a huge
> >> deal.
> >>
> >> That said, doing it more rarely, like every 5 seconds, sounds ok too.
> >>
> >> One solution is to punt the choice to the page. I.e. something like:
> >>
> >> [Constructor(StorageType type, unsigned long rate)]
> >> interface StorageWatcher {
> >>   readonly attribute StorageType type;
> >>   readonly attribute unsigned long rate;
> >>
> >>   attribute EventHandler onstoragechange;
> >> };
> >
> >
> >
> > Sorry for my slow response, while your suggestion looks pretty reasonable
> > I've been thinking about the battery consumption and possible usecases
> > when events could be useful. Major situations that came up to me are:
> >
> > 1. To watch the remaining storage capacity while the app is actively
> writing
> >    or deleting data  (<-- this is basically the case you mentioned)
> > 2. To be notified when the (shared) storage capacity is getting tight and
> >    their data may be evicted if they don't adjust their data size
> >
> > 1. could be useful if an app wants to keep their data within a certain
> > size (in temporary storage where they cannot specify an explicit quota),
> > while 2. is the situation I often hear requests for, and would be nice
> not
> > to waste too much battery.
> >
> > In either case I guessed frequency wouldn't be interesting but the actual
> > storage sizes may be.  What if we allow apps to specify specific size
> > thresholds?  The resulting API looks a bit noisy, but say,
> >
> > [Constructor(StorageType type, long long remainingStorageLow, optional
> long long usageHigh)]
> > interface StorageWatcher {
> >   readonly attribute StorageType type;
> >
> >   // Thresholds
> >   readonly long long remainingStorageLow;
> >   readonly long long usageHigh;
> >
> >   attribute EventHandler onstoragelow;
> >   attribute EventHandler onstorageok;
> > };
> >
> > Too rich?
> I don't quite understand usecase 2. Are you saying that a website want to
> be notified if it is at risk of it itself getting evicted? Or if it is at
> risk of evicting other websites?
>

Basically the former case, but maybe in a more implicit way. In general
keeping bigger data while the remaining space is tight increases the chance
of eviction, either on its own website or on other sites.  If a website
stores data that have different priorities in temporary storage, it may
want to cleanup their less-important data to decrease the chance that their
more-important data gets evicted (though it may just help other sites store
more data).

In the Gecko implementation neither really makes sense:
>
> As for a website getting itself evicted, we're planning on evicting
> websites on a strictly LRU basis. That means that storing more data doesn't
> increase the risk of getting evicted. There is no point at which a website
> could write so much data that we'd immediately, or more aggressively would
> evict it. The only limit is the quota limit that each website gets for
> temporary storage, but that limit doesn't really affect eviction, but
> rather just how much data can be written.
>
> As for a website causing other websites to get evicted, this is something
> that can, and probably will, happen as soon as a websites starts using
> temporary storage. Because the temporary storage has a global limit, and
> can be used without prompting, we're counting on eventually reaching that
> limit. Once that is done, as soon as a website starts writing *something*
> will need to get evicted. So trying to avoid evicting others this likely
> means not use temporary storage at all.
>
> Could you help me understand the policies that Chrome is using which
> motivates use case 2? And exactly what type of eviction that is the concern
> in that use case?
>

Sure... I think Chrome's policy is really similar to what is planned in
Gecko, but probably with minor variations, which may be causing some
misunderstanding between us.

In Chrome we do have a global limit for temporary storage, but the limit is
not fixed and may change over time when the actual remaining storage on the
local device changes.  E.g. when there's abundant disk space Chrome allows
websites to write more data, while when the disk space is getting tight it
may start evicting temporary data.

As in Gecko we evict websites based on LRU regardless of the amount the
site is storing, and the temporary quota only affects how much data can be
written.  But the global limit for temporary storage is shared by multiple
websites, and we assign temporary storage quota based on the current global
limit, so each site's temporary quota varies over time too.  Therefore it's
possible that Chrome once allowed a website to write a lot but then changes
its mind and start evicting things.

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?


> / Jonas
>