- From: Aaron Gustafson via GitHub <sysbot+gh@w3.org>
- Date: Thu, 27 Jun 2019 21:50:29 +0000
- To: public-device-apis-log@w3.org
> In general, I think that merging APIs should require a justification instead of splitting them in logical units. Normally, I’d be 100% with you. I’m just struggling to think of a use case that does not involve Wake Lock. Unless, of course, ChromeOS (or KaiOS) is interested in managing device brightness purely from web code. If that’s the case, separating might make sense. And in that instance, I could also see a desire for granular control over brightness level. When tied to wake lock, however, I think the broad strokes approach outlined above is ideal. I’m also not averse to having this feature exposed via a convenient configuration option when making a wake lock request. Perhaps a compromise would be to plumb the brightness controls separately, but not (yet) expose them as a distinct DOM API. That way the code remains separate and the features—wake lock and brightness control—are not directly tied together. Wake Lock could then call that separate API under the hood when the associated configuration option is used. It seems like that might be the most flexible approach, allowing us to focus on this use case now, but it also keeps all options on the table for a distinct API if some solid use cases materialize in the future. -- GitHub Notification of comment by aarongustafson Please view or discuss this issue at https://github.com/w3c/wake-lock/issues/129#issuecomment-506524654 using your GitHub account
Received on Thursday, 27 June 2019 21:50:30 UTC