Add an implementation-defined change threshold exceeded check #180
Conversation
- Define "contributing factors change threshold exceeded" steps - Call into these steps from the "change in data" steps - Add an informative note for implementation considerations Fix #176
index.html
Outdated
| </ol> | ||
| <aside class="note"> | ||
| The [=contributing factors change threshold exceeded=] algorithm allows user agents to avoid | ||
| flip-flopping between two states in certain circumstances. This specification does not define |
There was a problem hiding this comment.
I expanded this further with an abstract example.
- Expand the note with an abstract example - Clarify steps: Changes in [=contributing factors=] represented by |factors|
|
@kenchris thanks for the comments. I pushed an update, PTAL. This was a bit hard to define in abstract without defining the concrete algorithm normatively, which I don't want to do. Thus I proposed that short two-step algorithm and an accompanying note that tries to explain what's the problem and what implementers should do to improve. I think the significance of the changes to contributing factors need to be considered collectively. That is, a significant change in one metric may not exceed the threshold for the entire system if other metrics remain within their own bounds. Also, I wanted this to remain implementation-defined and thus I tried to avoid saying explicitly "if CPU utilization fluctuates around a boundary" to not steer implementers to think that is the metric to use. Please take another look. Further suggestions welcome. |
- Refactor "contributing factors change threshold exceeded" into "change in contributing factors is substantial" - Require no argument passing to this abstract algorithm to clarify and streamline related prose, refer to the current pressure state instead
- Refer to this internal slot in prose - Note: [[State]] represents the current pressure state
|
The PR has been updated with further refinements, PTAL. I think I'm soon satisfied with this. |
- We want to match the underlying hardware platform's behavior
| @@ -916,7 +943,8 @@ <h3>Supporting algorithms</h3> | |||
| Let |record:PressureRecord| be |observer|.{{PressureObserver/[[LastRecordMap]]}}[|source|]. | |||
There was a problem hiding this comment.
we should really rename this to lastRecord, it just confused me.
Fix #176
Preview | Diff