Comment 15 for bug 1750894

Thanks Kathy and Mike.

Mike, I hand't considered creating a build-time tool to generate them, but I could certainly see that being useful.

Regarding settings that fall back to local, tell me if this is what you are picturing, Mike.

1. Check if a user/ws setting type exists on the server (this can be bundled in to the setting value lookup for speed).

2. If no type exists at value change time, apply the value to local storage.

3. All subsequent value look-ups first check if a type/value exists on the server, then falls back to local storage copy.

4. If a setting type becomes available after its value was previously stored in local storage, the browser automatically migrates the value to the server setting and deletes the local copy.

Sound sane?

==

And as a reminder, there will also be a list of settings that never have server setting types. These will be things like ephemeral / cache data (last patron retrieved, etc.). These will likely be hard-coded in the browser settings lookup code (hatch) to avoid any unnecessary server calls.