- From: Raphael Kubo da Costa via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Sep 2024 12:56:25 +0000
- To: public-device-apis-log@w3.org
> The specification will recommend a rate limit of at most one update per second, though this is [=implementation-defined=]. We will also recommend that the call timings are jittered across contexts such as workers and main thread. * Why "this spec will recommend" instead of making this normative? * These requirements are always easier to follow and have an easier to measure impact when they are baked into the algorithms: * Are we talking about limits on the platform side or when delivering an update to each frame/worker? * Does there need to be any validation of the [`sampleInterval`](https://w3c.github.io/compute-pressure/#dom-pressureobserveroptions-sampleinterval) member passed to `PressureObserver.observe()`? * Similarly, is it enough for the spec to _recommend_ jitter or should it be a normative requirement? This spec has not required jittering values before; does it mean it was open to security issues being mitigated now or is this something completely new? > The rate limiting should be disabled during automation and for testing purposes, for reliable and quickly passing tests. We should avoid having separate paths for automation and non-automation. If the items above are integrated into the algorithms, you could allow setting them to some specific value via WebDriver, for example, or just write any tests in WPT in a way that does not depend on those values. In the worst case, defining some lower intervals for the automation case is better than not having any limiting altogether. -- GitHub Notification of comment by rakuco Please view or discuss this issue at https://github.com/w3c/compute-pressure/issues/291#issuecomment-2376878357 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 26 September 2024 12:56:26 UTC