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

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?


> / Jonas
>