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

@annevk - This ambiguity around the size of opaque responses should remain intact given that we include the padding in each entry in Cache Storage, and thus the `usageDetails` dictionary does not leak any additional information.

@annevk @domenic - Regarding obsoleted/proprietary storage backends, we would like to propose an alternative: The `usageDetails` dictionary would only contain members whose value is greater than 0.  This means that a site that doesn’t use proprietary APIs does not see proprietary members in `usageDetails`.  Your proposal seems reasonable, but we have concerns about what it would look like when deprecating a feature in the future.  Moving it’s usage to a deprecated dictionary is in itself a web-breaking change.

@asutherland @aliams - The primary goal of this change is to aid in debugging.  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 systems, this would mean the app is caching too many messages, suggesting the eviction policy is not behaving correctly. 

While we’d like to address the all-or-nothing eviction issue, any changes around the single temporary bucket are out of scope for this particular proposal.

@ralphch0 Thank you for providing your use case!  We’ll be sure to keep this in mind as we move forward.

-- 
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-438834042