Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make PressureObserver.observe() and data delivery algorithm less vague #283

Merged
merged 1 commit into from
Jun 14, 2024

Conversation

rakuco
Copy link
Member

@rakuco rakuco commented Jun 14, 2024

Related to #282: we need these algorithms to be properly defined in order to
be able to support WebDriver and fake pressure states.

This somewhat big change intends to clarify what "activate" and "deactivate"
data delivery actually mean, as there used to be just a "data delivery"
algorithm and no accompanying definitions for those two verbs. Furthermore,
the data delivery algorithm itself was confusing:

  • It referenced a data variable in its declaration that was never passed
    by any callers.
  • data was of an implementation-defined type and format, but the steps
    assumed it had some associated information like source type that was not
    set anywhere.

Fixing the above has required changes in different layers:

  • The "platform collector" concept, which used to be an abstract entity
    with which all globals interacted to retrieve telemetry data for all
    source types, is now a per-global and per-source type concept.
    The lower-level concept that represents a cross-global interface for the
    hardware or OS is now a "pressure source", which contains a snapshot of
    the latest reading it has retrieved along with a timestamp.
  • "Data delivery" is now called "data collection". It uses a platform
    collector and its associated pressure source to retrieve a telemetry
    sample that is transformed into a pressure state.
  • There are algorithms for activating and deactivating data collection. Both
    ensure they data collection cannot be started/stopped if they have already
    been.
  • PressureObserver.observe()'s had a "is not a valid source type" check
    that was too vague, as this step determined whether a given source type
    is supported by the platform or not, but the definition of "valid source
    type" was something else entirely.
    This step has been replaced by a sequence of steps that attempts to
    retrieve an existing platform collector for a source type and, if one does
    not exist, tries to connect to a corresponding pressure source. This
    change makes the same platform collector be used for all observers of a
    given source type and lays out in more detail what it means to check
    whether a source type is valid or not in this context.

Co-authored with @kenchris in #265. It was split off as a separate pull
request to make it easier to review and understand.


Preview | Diff

Related to #282: we need these algorithms to be properly defined in order to
be able to support WebDriver and fake pressure states.

This somewhat big change intends to clarify what "activate" and "deactivate"
data delivery actually mean, as there used to be just a "data delivery"
algorithm and no accompanying definitions for those two verbs. Furthermore,
the data delivery algorithm itself was confusing:
- It referenced a `data` variable in its declaration that was never passed
  by any callers.
- `data` was of an implementation-defined type and format, but the steps
  assumed it had some associated information like source type that was not
  set anywhere.

Fixing the above has required changes in different layers:
- The "platform collector" concept, which used to be an abstract entity
  with which all globals interacted to retrieve telemetry data for all
  source types, is now a per-global and per-source type concept.
  The lower-level concept that represents a cross-global interface for the
  hardware or OS is now a "pressure source", which contains a snapshot of
  the latest reading it has retrieved along with a timestamp.
- "Data delivery" is now called "data collection". It uses a platform
  collector and its associated pressure source to retrieve a telemetry
  sample that is transformed into a pressure state.
- There are algorithms for activating and deactivating data collection. Both
  ensure they data collection cannot be started/stopped if they have already
  been.
- `PressureObserver.observe()`'s had a "is not a valid source type" check
  that was too vague, as this step determined whether a given source type
  is supported by the platform or not, but the definition of "valid source
  type" was something else entirely.
  This step has been replaced by a sequence of steps that attempts to
  retrieve an existing platform collector for a source type and, if one does
  not exist, tries to connect to a corresponding pressure source. This
  change makes the same platform collector be used for all observers of a
  given source type and lays out in more detail what it means to check
  whether a source type is valid or not in this context.

Co-authored with @kenchris in #265. It was split off as a separate pull
request to make it easier to review and understand.
@rakuco rakuco requested review from kenchris and arskama June 14, 2024 11:31
@rakuco
Copy link
Member Author

rakuco commented Jun 14, 2024

@kenchris @arskama the contents are all in #265. This is the part of that PR that is unrelated to WebDriver. Hopefully it's easier to review here.

index.html Show resolved Hide resolved
@rakuco rakuco merged commit 10b4251 into main Jun 14, 2024
2 checks passed
@rakuco rakuco deleted the concepts-and-more-precise-algorithms branch June 14, 2024 12:27
arskama added a commit to arskama/compute-pressure that referenced this pull request Jun 14, 2024
Adding Raphael after his large contribution.

Clarification in specification: w3c#283
Automation section: w3c#284
anssiko pushed a commit that referenced this pull request Jun 17, 2024
Adding Raphael as an editor. Some of his recent contributions include:

Clarification in specification: #283
Automation section: #284
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants