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/

Reply via email to