Re: [w3c/ServiceWorker] A simple globally available store of data per-registration (#1331)

This also came up in https://github.com/w3c/ServiceWorker/issues/1157.  Having some small set of synchronously available data seems to be a recurring request.

As an implementer, I'd posit the most important things in such an API are:
1. It only be allowed a **very** small amount of data.  So small that it's clear the data is precious and content code immediately be worried about headroom rather than letting it be a can that gets kicked down the road and eventually browsers have to preload a megabyte of data every time a SW gets loaded and/or turn to complicated data-race implementations like they use for localStorage.  AKA If it's small enough, no one has to worry about falling off the fast path.
2. The exact data limits be exactly specified by the standard so there's not a circular cycle of browser implementations loosening their limits as the vagaries of structured clone persistence sizes cause site-breakage which enables more cycles of expansion.

[URLSearchParams](https://url.spec.whatwg.org/#urlsearchparams) is roughly an example of such an existing API that could be abused.  It has a string serialization, and the size constraint could be on registration.params.toString().length.  This encoding also lends itself to simple tunneling of the state from the server.

-- 
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/1331#issuecomment-403624838

Received on Monday, 9 July 2018 21:23:15 UTC