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

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?

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?

/ Jonas