- From: Marijn Kruisselbrink <notifications@github.com>
- Date: Thu, 17 Dec 2020 09:46:10 -0800
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Thursday, 17 December 2020 17:46:23 UTC
I agree that storing in cache storage does seem like the way to go here. > We could be serving a large amount of local content, corresponding to an entire game. The user may not have enough storage quota to save the whole map. For what it's worth, in Chrome we are considering counting temporary blobs against an origins storage quota as well. But at least compared to other browsers Chrome is probably more generous with storage quota anyway, so that shouldn't be a problem (I think storage quota for a single origin is typically larger than the total quota for blobs we allow today). Lacking a way of moving a blob to cache storage or IndexedDB writing it to storage will temporarily increase the total quota needed. It might be theoretically possible to support such a move operation, but that has the risk of severely limiting what optimizations etc implementations can do to make blobs behave sanely in general (i.e. blob slices sharing storage, etc). Tthe on-disk formats of temporary blobs and blobs in storage APIs being different would also still mean that even if we had such a hypothetical move operation it would probably still need to be implemented by copying and then deleting the original. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/issues/1558#issuecomment-747594107
Received on Thursday, 17 December 2020 17:46:23 UTC