"Valid source type" check in PressureObserver.observe() needs more details #273
Comments
rakuco
pushed a commit
to kenchris/compute-pressure
that referenced
this issue
Jun 4, 2024
…tion/deactivation This addresses w3c#265 (comment) by properly defining several concepts in one change: - "Pressure source" is now a proper `<dfn>`. It is similar to a "device sensor" in the Generic Sensor API spec, in that it works as the concept closest to the OS/hardware and retrieves some abstract telemetry data that is fed to one or more platform collectors. A virtual pressure source is a pressure source. - Platform collector's granularity has been fixed: there isn't one per global, but rather one per source type. To make it easier to follow, a global now has a "platform collector mapping" rather than just an associated platform collector. - Each platform collector now has some associated data: an "associated pressure source", which is the pressure source it retrieves data from, as well as an "activated" flag that is used when activating/deactivating data collection. With these new building blocks, we can fix and/or properly define some concepts that have been unclear so far: - A null associated pressure source indicates that a given pressure source is not available. This is used, for example, in `PressureObserver.observe()`, which is now responsible for creating a platform collector when one is not available in its global and attempting to set the platform collector's associated pressure source to either a virtual pressure source or a real one. When neither can be found, it remains null, which signals that `observe()` must reject with NotSupportedError. Previously (see w3c#273), the `observe()` steps simply checked if `|source|` was a "valid source type", which did not properly reflect the potentially asynchronous checks involved in the real pressure source case. - The absence of an entry for a given source type in the "platform collector mapping" indicates that `PressureObserver.observe()` must attempt to create a new platform collector as described above. An existing "platform collector mapping" entry is removed only by calls to `disconnect()` and `unobserve()` as well as when a document is no longer fully active or a worker's closing flag is set to true. Conceptually, this indicates more clearly that once a platform collector is created in `observe()` it will continue using the same associated pressure source. In other words, if `observe()` is called before "create virtual pressure source", all observers for the same source type will continue using a real pressure source until they all disconnect (and vice-versa). - A virtual pressure source keeps track of connected platform collectors so that it can set their associated pressure source to null when it is removed before they disconnect. This is used in the new data collection algorithm described below. - The data collection steps have been revamped. - "Data collection" itself has not changed much: it tries to get a platform collector's pressure source if one exists, read data from it and dispatch it to observers. - We finally have proper definitions for what it means to activate and deactivate data collection. The steps themselves do not do much besides making sure 1) a platform collector for the desired source exists and 2) these steps cannot run more than once for a platform collector. The "deactivate data collection" steps also takes care of removing a collector from a virtual pressure source's connected platform collectors set.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The current text says:
It is not very clear how to determine whether a given source type is valid or not: https://w3c.github.io/compute-pressure/#dfn-valid-source-types just says "global system thermals" and "central processing unit" (as represented in PressureSource) are the valid source types, but the check in
observe()is really for whether a source type is supported by the underlying platform/hardware rather than being "valid" from a spec sense.I think
observe()should use some different concept that better represents what it is trying to do, which could also integrate more nicely with the automation steps (since a virtual pressure source could be configured to report itself as non-existent).The text was updated successfully, but these errors were encountered: