Lea: my primary concern is it might be too low level. All the use cases are about an app resonding to high CPU load. What constitutes high CPU? Two kinds: utilisaiton threshold and clock speed and they need to provide thresholds for both. This would make more sense as an observer for.. there's high load right now, or no high load any more. All the use cases they listed don't depend on specific thresholds, but on apps lowering use of resources when there's high load. Tying it to hardware makes it less futureproof. I'd like someone else to review security and privacy if they stay with this current design. Because they aggregate these numbers across all CPUs they're not exposing sensitive information, but would be good if someone else could review the questionnaire responses. Minor feedback - using an observer but the method to start observing is not called observe, but start, so should be harmonized with other observers.

Dan: [reviewing S&P questionnaire responses]

Peter: the test modes seems kind of weird. And GPU as well? Would that be part of this?

Lea: I had mixed thoughts about the test mode. It's good they thought of debugging, but it is kind of weird and not consistent with anything else.

Peter: I have no problem with debug mode, but weird as part of API surface, maybe a browser switch or something.

Dan: current spec is too specific? A binary switch of high cpu or not high cpu, or is the proposal to have more granular?

Lea: I worry it's too granular and too hardware specific, but I might be wrong.

Peter: agree that a simple high usage mode or throttled would be better than the number they're exposing now. Felt odd. Pinning base CPU to 0.5 and max to 1 seemed weird. You're going to have a different range between 0 and .5 as you are between .5 and 1. They talk about linearizing it but I don't think the math works out.

Dan: for keeping it simple, having it be one single thing makes more sense and then we'll see if developers take advantage of that, vs building a whole complex thing and it turns out it doesn't get much use.

Lea: sounds like we're in agreement, I could leave a comment.

Proposed comment:

We reviewed this during a breakout today. Since all use cases listed relate to web applications responding to high load, we are wondering if a simpler, less granular, more high level API would address these use cases equally well, without the added complexity of specific thresholds, different for CPU utilization and CPU speed. See Prefer Simple Solutions.

If not, it would be good to show use-cases where this is not the case. We assume the reason might be to know well ahead whether you are about to get throttled and it is less interesting knowing when you are being throttled. Is that correct?

We understand that all speeds are being rescaled to a percentages, instead of revealing actual top speeds etc which really helps with privacy, so we welcome that.

In terms of the proposed API, please note that all other observers on the Web Platform today use observer.observe() instead of observer.start(). Also, while it's good that debugging use cases were considered, we think that a test mode would be more appropriate as a browser dev tools switch instead of part of the API surface.

The spec has to handle heterogenous computing where the CPU has different kinds of cores (ARM BIG.little, Intel Alder Lake). The software/hardware scheduler can move workloads (such as browser process) to another core with different characteristics, like you might be about to max out the little cores, then you are moved to another core with plenty of performance budget left. This may lead to confusing numbers when it is expressed as a single scalar.

They need to explain more about why CPU utilization and clock speed are both needed. Would it be better to have a higher level "CPU load" factor? More complexity could be available, but shouldn't be mandatory.

Lea: still waiting for a response

Ken: a lot of this is still up in the air. The main driver behind it from google is on a sabbatical until the end of september. I'd say punt this. a lot of discussion behind the scenes. Postponed, we gave a lot of feedback, waiting for them to come back and say what we do

Dan: close for no with a note saying we understand there are delays

Ken: I don't think it needs to be closed, can't we postpone it?

Lea: seems more reasonable to postpone it. Til October?

Dan: need a new status? Stalled?

Ken: stalled sounds negative

Lea: and passive agressive

Sangwhan: why not pending external feedback?

Lea: that seems the closest

Ken: just set a milestone for the future

Dan: [leaves comment]

Sangwhan: there is pushback - webkit thinks this is problematic. can be coordinated between 2 origins... mozilla said the same. We asked the question to the OP on whether they have engaged with other implemenetrs on this.

Ken: not much has happened yet, someone else is taking over. Should be restarting the discussios at tpac. Bump it.

Ken: someone new is taking over.. maybe Intel

Dan: so nobody currently driving this?

Ken: officially they're still working on it. There are people with interest in it, but can't commit to anything. Hopefully will know soon

Dan: [...sounds like some resourcing issues...]

Ken: Intel is taking over, not sure of status, will reopen the issue when we're ready. Proposed close?