Re: [compute-pressure] Get rid of the promise returned by observe (#258)

Some quick answers first:
- It's not that `setTimeout()` is not allowed in tests; I think @arskama was referring to using [`t.step_timeout()`](https://web-platform-tests.org/writing-tests/testharness-api.html#Test.step_timeout) in web-platform-tests instead of calls to `setTimeout()`. But even then, the bigger problem is that using timeouts to detect that something did _not_ happen is very flaky: timeout values often do not work well in CI, and it makes testing very unpredictable.
- WebDriver BiDi is the bidirectional version of the WebDriver protocol. It's under development, and the tooling in web-platform-tests is not there yet (i.e. one [cannot use testdriver.js with BiDi](https://github.com/web-platform-tests/wpt/issues/45404)). In any case...
- ... Having "events just for tests" is generally not a good idea. There shouldn't be special behavior that only happens in tests, otherwise you're not really testing the actual API. Furthermore, even if we did use WebDriver BiDi and defined a way to send a notification if something failed, users would probably want access to the same information anyway (it's the whole point about timeouts being arbitrary above).

Now looking at other Observer-style APIs, I think this one is inevitably more asynchronous than the others, and `observe()` needs to check if a given source type is supported by the platform or not in an asynchronous manner -- my understanding is that the `supportedSources` attribute lists the types that _can_ be supported by an implementation, but whether the hardware or OS-level support (together with any permission mechanisms that might exist outside the scope of this API) is only checked when `observe()` is called.

So if we take into account that there's one asynchronous step that we can't get rid of, and there might be others in the future, maybe getting rid of the promise is not a good idea. The API could take a failure callback like you described, or it could fire an "error" event if something in observe() goes wrong, but it feels like this is going against the [design asynchronous APIs using Promises TAG advice](https://w3ctag.github.io/design-principles/#promises).

The problem of the ergonomics of supporting multiple sources in one call is real though, but I wonder if any of the other solutions above would solve this problem better.

Would it be _that_ important to support multiple sources in one call instead of having developers do something like `Promise.all([observer.observe('gpu'), observer.observe('thermal', options), observer.observe('gpu', options)])`?

-- 
GitHub Notification of comment by rakuco
Please view or discuss this issue at https://github.com/w3c/compute-pressure/issues/258#issuecomment-2047724262 using your GitHub account


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

Received on Wednesday, 10 April 2024 14:34:08 UTC