Re: [whatwg/storage] Define size of all storage actions (#110)

This seems desirable and has indeed come up before.  Specifically, in terms of allowing structured serialized storage of data on things like ServiceWorker registrations and related data (ex: [Notification.data](https://notifications.spec.whatwg.org/#dom-notification-data)) where it would be desirable to place an upper bound on storage but is an interop nightmare without this issue addressed.

I believe this would require the [serialization steps](https://html.spec.whatwg.org/multipage/structured-data.html#serialization-steps) for `[Serializable]` to also produce a size/upper-bound value as well?

It seems like the most complex issues are;
1. Blob/File and any similarly immutable abstractions which allow implementations like IndexedDB to store a single copy of the data on disk.  Firefox only stores a single copy of a given Blob/File (based on object identity, independent of contents).  I presume the only course of action is to either standardize this or to tally each time the blob is used in a [structured serialization](https://html.spec.whatwg.org/multipage/structured-data.html#structuredserializeinternal) (which will be-duplicate internally via  its "memory").  If standardized, interesting and terrifying new possibilities are raised, such as the BlobStore being its own storage endpoint which can then be used by [Notification.data](https://notifications.spec.whatwg.org/#dom-notification-data) and even ServiceWorker's Cache API storage.
2. Compression.  It would be unfortunate for implementations to be able to implement CPU/power/disk-efficient native storage of data but need to charge a high quota cost, resulting in content performing less efficient compression in JS/WASM in order to be charged a lower quota cost but actually use more disk space.  Presumably the answer is [Compression Streams](https://wicg.github.io/compression/)?  But this is still awkward because, for example, Firefox currently uses Snappy (for Cache API storage) and wants to use LZ4 (for Cache API storage and IndexedDB), and neither of those are yet specified and it would be arguably silly to run gzip against data just for the purposes of calculating a more generous quota charge while actually storing the data using LZ4.



-- 
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/110#issuecomment-656825262