Re: [screen-wake-lock] editorial: Tidy up uses of "in parallel". (#299)

Some thoughts:

* obtain permission shouldn't run in parallel, it should be invoked from in parallel, but it doesn't make sense for it itself to then also go in parallel again (in parallel steps cannot return things)
* A slightly clearer style is to say "run these steps in parallel" and then have a subsequent step return the promise.
* You really want to use "queue a global task" and always pass it the global and task source to use explicitly. That's the way forward.

In parallel usage otherwise seems reasonable from a quick skim. (If you're still not too sure about it, HTML has a bunch of guidance language for it, it's basically akin to a thread/process. Also happy to chat at https://whatwg.org/irc or equivalent.)

Questions:

* I'm not sure about hidden documents. There are some issues about this against HTML as well. (Checking the `hidden` attribute is definitely wrong though. You don't want to invoke IDL members in your algorithms as a general rule.)
* I'm not sure I understand this.
* Yeah, it seems "acquire a wake lock" could be run twice if you invoke the method twice.
* The order of event/promise in `release()` seems fine. It might be clearer to run "release a wake lock" when the slot is false and then have a single return step at the end. 
   * If you don't want `release()` to fire an event directly (though not sure if it matters much), you could make it queue a task to run "release a wake lock" and resolve the promise with undefined. That way other callers of "release a wake lock" would still dispatch the event in whatever task they find themselves in.

-- 
GitHub Notification of comment by annevk
Please view or discuss this issue at https://github.com/w3c/screen-wake-lock/pull/299#issuecomment-777325410 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 11 February 2021 09:56:10 UTC