- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Fri, 28 Feb 2025 08:54:25 +0000
- To: public-webrtc-logs@w3.org
> I think the concern in this case is: > > 1. lack of cap on frequency might lead two browsers to implement vastly different intervals, e.g. 1 vs 15 seconds. > 2. whether an anticipated use case is A/B codec testing where a website might tune its interval to the fastest browser Polling is just asking "do you have any new measurements for me?" Whether I poll once per 15 seconds and get that measurement on the first try or if I poll getStats 15 times and get 14 "no's" and 1 "yes", I think I end up in the same situation, so what exactly was the problem there (and why is this different from the other hundred+ metrics we have)? It doesn't matter if app polling interval and browser polling interval aligns or not and it's clear from the [guidelines](https://w3c.github.io/webrtc-stats/#guidelines-for-design-of-stats-objects) that there is no control of sampling period. So I would argue that the only thing that matters is if the measurements are arriving at a granular enough level to be useful. If the concern is that a browser implementer doesn't know what a useful measurement interval is, maybe we can provide some guidance there, but I fail to see the interop issue with different polling intervals that are all within a "useful" range. FTR I think 15 second is too large of an interval since a lot can happen in that period of time. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-stats/pull/794#issuecomment-2690081367 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 28 February 2025 08:54:26 UTC