- From: Loïc Faure-Lacroix <notifications@github.com>
- Date: Wed, 04 Oct 2023 12:13:27 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/1694@github.com>
Currently, the cache storage is mainly useful to store into a cache a response that matches somehow a request. So if you have a request already cached a very similar request can be found in the cache. It's fine but sometimes, it's just not enough to be very useful. Currently, the only way you can query the cache storage is by fetching the keys and passing them through a custom router that would allow you to find a key that matches your criteria. The other way which might be a bit easier is to implement a custom database storage in an IndexedDB with the indexes that you need to search on. For example, let say you had such url: `/store/templates/xml/1?bundle=bundle1` Think of it like a xml template of version 1 and taking a bundle from this template called bundle1. Basically, the query could try to find a bundle of the most recent version that is in the cache. So a search on: "/store/template/xml/(?<version>\w+)\?bundle=(?<bundle>\w+)" It would be nice if we could query the storage with something like a range or exact match. cache.query( /\/store\/template\/xml\/(?<version>\w+)\?bundle=(?<bundle>\w+)/, { bundle: 'bundle1', version: new Range(0, new Date().valueOf()) } ) Or possibly allow a way to create indexes that can be queried. cache.createIndex('templates', (request) => extract_keys(request)) // ['bundle1', 1] Then simply the index by taking a value from it using a key or range and possibly add a way to change the order in which the keys of the index are stored. cache.index('templates').search(['bundle1']) // gets all bundle1 regardless of the version cache.index('templates').search(['bundle1'], ['bundle1', 10]) // gets all bundle with a version less than 10. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/issues/1694 You are receiving this because you are subscribed to this thread. Message ID: <w3c/ServiceWorker/issues/1694@github.com>
Received on Wednesday, 4 October 2023 19:13:33 UTC