#85: Storage persistence
Discussions
Comment by @slightlyoff Jan 14, 2016 (See Github)
As a minimal subset of the Storage API, this looks good. A few questions:
- these APIs look good, particularly as they don't put any constraints on browsers about UI and actual decisions about storage
- would like to see a callout to the TAG finding on Unsanctioned User Tracking and positive user controls so that implementers understand that they need to allow users control over this
- what is the reflection of the
persistentPermission()
in the Permissions API? If there isn't one, I'd like to see it proposed soon. - the text in the Storage spec around quota is...odd? It doesn't seem to relate in any way to existing Quota drafts and proposes a whole set of box-specialized methods (
estimate()
andpersistentEstimate()
) without any sort of explainer or example code to illustrate how they'd work in common scenarios which developers encounter. Which brings us to... - ...this spec doesn't have an explainer and a single example which covers almost none of the draft feature capability. This is a red flag.
As Chrome is only interested in requestPersistent()
and persistentPermission()
for now, the rest of the spec seems out of scope for this review. That said, we'd like to be informed if implementers are considering the rest as it raises many concerns.
/cc @kinu @inexorabletash @khuey @travisleithead
Comment by @khuey Feb 8, 2016 (See Github)
The ordering of persistentPermission and requestPersistent in https://storage.spec.whatwg.org/#dom-storagemanager-persistentpermission seems slightly odd. What's the rationale for that?
Also, is there a reason not to allow workers to requestPersistent?
/cc @wanderview @bakulf
Comment by @inexorabletash Feb 8, 2016 (See Github)
Workers requesting permissions at all needs to be sorted in general, due to lack of UI surface. (Obviously they could delegate to owning window, etc, but no-one is doing that yet IIRC.) I think I saw some chatter recently about doing this for geolocation.
On Feb 8, 2016, at 2:05 PM, Kyle Huey notifications@github.com wrote:
The ordering of persistentPermission and requestPersistent in https://storage.spec.whatwg.org/#dom-storagemanager-persistentpermission seems slightly odd. What's the rationale for that?
Also, is there a reason not to allow workers to requestPersistent?
/cc @wanderview @bakulf
— Reply to this email directly or view it on GitHub.
Comment by @khuey Feb 8, 2016 (See Github)
Right. If the expectation is that we will change in the future, I am satisfied.
Comment by @annevk Feb 9, 2016 (See Github)
If you could file issues at https://github.com/whatwg/storage/issues that would help. Happy to change things.
Comment by @slightlyoff Mar 30, 2016 (See Github)
Filed.
Comment by @annevk Mar 30, 2016 (See Github)
Thanks.
Comment by @annevk Apr 1, 2016 (See Github)
Addressed.
Comment by @hadleybeeman Jul 30, 2016 (See Github)
discussed at stockholm f2f and agreed to close
OpenedSep 24, 2015
Could someone review two methods from the storage API that chrome would like to ship? That is:
navigator.storage.requestPersistent()
navigator.storage.persistentPermission()
/cc @annevk