| 08:33 | <Andreu Botella> | I'm looking at the task termination doc, and from the listed use cases it seems like task terminations wouldn't be exposed as user-visible metrics or events, it would just be browser-internal, right? |
| 08:35 | <Andreu Botella> | and an implementation of task attribution with unbounded queues (assuming infinite memory and processing power) would be equivalent to one with task termination |
| 08:36 | <Andreu Botella> | If so, I'm not sure why there needs to be a spec for it, just a note on the task attribution spec describing implementation considerations would suffice, right? |
| 10:10 | <littledan> | For the use cases Yoav presented (eg perf metrics), a lot of people need to be coordinated around the definition of when this termination event happens, both within Chrome, among other browsers who would hopefully eventually do something similar, as well as web developers. Coordinating expectations to guide implementations and usages is exactly what a standard is for. |
| 10:12 | <littledan> | Also sometimes it’s useful for specs to present a more or less realistic way to implement things, to enable people to implement it more straightforwardly. |
| 10:15 | <Andreu Botella> | Web developers need coordination in terms of when the perf metrics happen, not in terms of when a task attribution scope gets evicted |
| 10:37 | <littledan> | Isn’t the second part of the first? |
| 10:52 | <Andreu Botella> | AFAIU the actual eviction isn't exposed to developers |
| 12:41 | <littledan> | sure, it just potentially affects the timing of the callback. Lots of mechanisms in the HTML spec aren't exposed to developers directly. |
| 12:42 | <littledan> | Even just coordinating among all the Chrome engineers and other browser developers requires some very detailed documentation which everyone can agree on, at least |
| 12:47 | <Andreu Botella> | If there is a callback it can affect the timing of, then it should be specified indeed |
| 12:47 | <Andreu Botella> | But the tasks descending from mouseovers use case doesn't require that |
| 12:48 | <Andreu Botella> | The soft navigation durations use case might, but I'm not sure, and the issue doesn't talk about using task termination directly |
| 12:50 | <littledan> | Many performance events are exposed to JS, e.g., https://w3c.github.io/largest-contentful-paint/ . But even if this one weren't, and only available in dev tools, I don't think that affects whether it can be useful to coordinate deeply on what is being measured. |
| 12:51 | <Andreu Botella> | The tasks descending from mouseovers use case, again AFAIU, is only a concern with memory pressure in the browser, it's not a performance event |
| 12:52 | <littledan> | I'm really confused; I'm not sure what you're getting at |
| 12:57 | <Andreu Botella> | It seems like at least two out of the three use cases described in the task termination design doc are only useful to avoid having to lose task attribution tasks when the number of tasks that would otherwise have to be tracked grows |
| 12:58 | <Andreu Botella> | If we imagine a spherical-frictionless-cow implementation with no memory limits, for those two use cases, task termination would not be needed |
| 12:58 | <Andreu Botella> | And it's typical to assume spherical frictionless cow implementations in specs |
| 13:05 | <Andreu Botella> | I wouldn't be opposed to specifying task termination, and I see the point in enabling coordination, but not only browser engineers read the specs |