Re: [w3ctag/spec-reviews] Review of WakeLock API and suitability for overall platform requested by 31 August 2016 (#126)

My review comments:

* Great use cases--made it clear why the feature is needed and important!
* The API is a simple Boolean property. As such, it has graceful fallback for user agents that don't intend to support it (setting the property when the property does not exist does not cause an exception to program control flow). This is a strong benefit of the current design.
* Conversely, as a simple Boolean property, there is no ability to extend the feature (if needed). For example, if the application would like to specify some kind of timeout period, then a new property would need to be added (this is not bad per-se, just that the functionality could not be conveniently combined into a single API call). Such things are generally extended through dictionaries, and there's no way to provide a dictionary to a Boolean property.
* Since the property only corresponds to the _request_ for the wake lock, there is no mechanism provided to discover if the wake lock request succeeded or failed--e.g., is wake lock actually going to be applied. IMO this lack of awareness on behalf of the application is OK because (in the case that the lock cannot be applied for some reason) the app is no worse off than the current status-quo in user agents today.
* the Lifecycle model of the wake lock is well-described.
* Section 7 (and other relevant sections) allow large latitude for user agents to take environmental factors into play when granting or revoking a wake lock. This is appropriate.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/126#issuecomment-242101530