On Wed, Mar 18, 2015 at 1:38 AM, Krinkle <krinklem...@gmail.com> wrote: > I'd like to share a use case and problem we have at Wikipedia with > localStorage.
Thanks, this is great feedback. > I imagine HTTP2 might make it appropriate to phase out batches and just > request modules individually (always) and let the network layer do the > combining and separated caching in a more natural way. Yeah, hopefully. > * A way to know if a url is cached or not (e.g. know whether a url will hit > HTTP 304) without making the request. Maybe we can expose that same-origin, not sure. Depends a bit on the implementer feedback we get for fetch()' cache feature. But privacy-wise it's somewhat problematic to reveal what is in the cache as the cache is not unique per-origin. > * A way to prioritise which entries should be kept in localStorage and allow > for low-prio entries to be evicted if short on space. > * A way to know how much localStorage is available in total. > * Perhaps a way to create a limited store within localStorage or IndexDB > that has limited/restricted capacity (with some unique identifier, capacity > percentage-based, or a min/max byte size?). > * A separate store for caching HTTP resources (the Service Worker's Cache > API?) The current setup is basically a storage area per site with LRU semantics. It's not completely done yet as not all storage features share the same store, but they will eventually. Persistence is planned as per OP. We have two other ideas roughly along the lines of what you ask for: 1) Allow a site to mint new storage areas. If we keep doing LRU on storage areas rather than sites that would allow for e.g. a game engine staying preserved while the initial set of levels (one per storage area) that are no longer played are cleared. 2) A storage area that acts like a cache. Resources that are not frequently used get deleted before those that get frequently used get deleted. -- https://annevankesteren.nl/