Intent to Ship: Storage Quota Usage Details

[Jarryd Goodman]

Contact emails

jar...@chromium.org

Explainer

https://github.com/whatwg/storage/issues/63#issuecomment-441857897

Spec

Skipping the TAG review because this is a minor addition.

Summary

This change adds a dictionary to the returned dictionary of storageManager.estimate() that contains details about usage for each storage backend. The goal is to aid in debugging issues around overuse of specific storage systems.

Motivation

There have been frequent requests from users of `navigator.storage.estimate()` to provide a per storage type breakdown estimation.  Currently, a call to this function yields only an estimate of the quota usage for all storage systems combined, making it difficult to reason about what is using up quota.  With a detailed per system usage breakdown, apps are provided more context and clues to detect and diagnose storage overuse problems.

For example, one can consider an email client that uses IndexedDB to store text and Cache Storage to store attachments.  With the proposed change, said app would be able to debug problematic storage scenarios: high Cache Storage usage but low IndexedDB usage would suggest the app forgot to delete attachments when evicting messages from the local cache.  If there was high usage for both storage backends, this would mean the app is caching too many messages, suggesting the eviction policy is not behaving correctly.

Link to “Intent to Implement” blink-dev discussion

Intent to Implement: Storage Quota Usage Details - Google Groups

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Debuggability

The information returned by this API is already shown in DevTools.

Risks

Interoperability and Compatibility

Edge: No signals

Firefox: Public support

Safari: No signals

Web developers: Positive

We have positive feedback on this API from a major Google property.

Ergonomics

No ergonomic issues.  The change is extending a modern promise-based API.

Activation

The new usage details dictionary is added to the return value of a method that already exists, so this new information should be easy to consume.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

https://github.com/web-platform-tests/wpt/pull/14531

https://github.com/web-platform-tests/wpt/pull/13883/

Entry on the feature dashboard

[Daniel Bratell]

While this looks like a useful addition, I think it's prudent to have it landed into the specification before shipping it. One thing in particular struck me when I read the issue and that was the intent to have it scale to further "buckets". The API doesn't naturally look scalable so I wonder if the API will have to change further before landing. 

/Daniel

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEHjowyuNPMM2mxD8_eP2j3Jbn2cRim_QYiToO5yADc6aoxFMg%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Jarryd Goodman]

I believe you are referring to what I said on the github issue:

We do expect that, in the future, consumers will have more buckets than the default bucket. We see the proposed change as a complement to said future rather than a redundancy. Each bucket will still have access to all the storage backends, so we will still want an API that, given a bucket, will return the per system usage details.

 You've raised a fair point in that it's not obvious how this API is extensible with respect to buckets.  In a future where we have buckets, we believe this API can be extended in two ways:

1. Each bucket will expose this API and the `usageDetails` in the response would show a breakdown for storage within the scope of said bucket.
2. We add a `buckets` dictionary that has total usage and breakdown for each bucket.

I hope that helps clarify things, but if not, I'm happy to VC to resolve any related outstanding ambiguities.

[Daniel Bratell]

I just need to be convinced that the proposed API is the final shape of the API and the best way to do that is to land it in the specification. You got support for your suggestion in November so it is hopefully just a question of making a pull request and have that one accepted, but until then it's too tentative.

/Daniel

[Jarryd Goodman]

Just an update here: I've gone ahead and filed for TAG review and opened a spec PR.  I've also created an explainer that one can also find linked in the TAG issue.

[Daniel Bratell]

Thanks! Not much movement yet. Anyone here that can give them a push?

/Daniel

[Alex Russell]

I will.

[Yoav Weiss]

A month later, not much movement, other than questions from Lukasz Olejnik with good responses to them. So, I don't think we should block any longer.

LGTM1

On Thu, May 2, 2019 at 9:32 PM 'Alex Russell' via blink-dev <blin...@chromium.org> wrote:

I will.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5dab5d88-9c1b-4878-bce2-7e18c4cb2c0c%40chromium.org.

[Daniel Bratell]

LGTM2

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgpuYvuPx-qLa_OOwN27hqhv_sbiXSep3unZmMOg86C7g%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/op.z2y73nbbrbppqq%40cicero2.linkoping.osa.