Re: [whatwg/storage] Proposal: Add detailed usage breakdown in estimate() (#63)

@jarryd999 Can you further elaborate on how the Google properties intend to use this extra data?

Like, is the idea that Cache storage will always be treated as evictable and IndexedDB always as canonical, so Cache can be ignored for storage pressure reasons and only IndexedDB matters?  Or is this desired for telemetry so that engineers can say "holy cow, we've got a ton of WebSQL storage still used, we'd better push additional telemetry gathering for WebSQL/push specific cleanup logic/send clear-site-data anyone reporting that data and star from scratch", etc. ?

I ask because one of the issues that came up a few times at the 2018 TPAC was the idea that eviction is still problematic because there's still only a single storage "[bucket](https://storage.spec.whatwg.org/#buckets)" and things like the relationship between a ServiceWorker registration and the storages it used exists only in the mind of the developers who wrote the code so we continue to be faced with all-or-nothing eviction.  It seems like both browsers and the various teams on a site would benefit if we implemented multiple buckets and our estimate included usage by bucket.

Obviously, more buckets is not a simple change since it would have to be plumbed through all existing APIs and there's still the issue of pre-existing data.  So the other question in my mind is how are these top-level summaries more useful than returning size-estimates at a more detailed granularity?

For example, in Firefox we have a memory reporting infrastructure "[about:memory"](https://developer.mozilla.org/en-US/docs/Mozilla/Performance/about:memory) ([and the underlying API](https://searchfox.org/mozilla-central/source/xpcom/base/nsIMemoryReporter.idl)) that provides a hierarchical summation of our memory usage.  I could see it being very useful to have entries for "indexedDB/foo" and perhaps "indexedDB/foo/blobs", "indexedDB/foo/key-values", and "indexedDB/foo/indexes".  Perhaps even "indexedDB/foo/key-values/large-values" and "indexedDB/foo/key-values/small-values", etc.

The idea there would be that we could spec some explicit names for the top-level of the hierarchy and immediate children, but that browsers could go into more implementation-specific detail if they wanted and it was requested.  I imagine we'd limit that level of detail to our own devtools initially, stopping at "indexedDB/DBNAME" granularity for content.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/storage/issues/63#issuecomment-438270976