On Mon, Feb 20, 2023 at 12:52 PM Henrik Boström <h...@chromium.org> wrote:
> OK, so deprecation warning in M113, throwing in Beta in M114 and throwing > in Stable on M119. We can do that. Awesome! > Under this less aggressive timeline, for how many more milestones would > the Deprecation Trial span? > How much would be needed for people to schedule the work to make the switch? > > I do not have any more deprecations planned on my end and I think this is > "standalone" enough (stats being rather specific) that in my opinion it > should not be bundled together with anything else. > OK, cool! > On Friday, February 17, 2023 at 8:52:56 AM UTC+1 Yoav Weiss wrote: > >> Hey Henrik! >> >> I think the general outline of the plan makes sense, but the timelines >> seem too aggressive. As we've recently seen in the track stats removal, >> there can be a time difference between the point a developer puts in the >> work to opt-in for a deprecation trial and the point in which this work >> reaches users. >> >> I think it would make sense to: >> * Add a deprecation warning in M113 and enable a Deprecation Trial. Set a >> tentative removal milestone for M119. >> * Start throwing an exception up to Beta in M114 to try and get people's >> attention >> * Broadly communicate this change is coming in multiple channels. DevRel >> folks may be able to help there. +Paul Kinlan <paulkin...@google.com> >> and +Andre Bandarra <andre...@google.com> for thoughts. >> * In parallel to the above, turn the usecounters into UKM >> <https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=14?q=usecounter%20ukm&ss=chromium>, >> and try to see where most usage lies. (and try to understand if it's coming >> from libraries with longer deployment lifecycles) >> * Flip the switch (and be ready to revert) in M119 >> >> I know this is a bit longer and more work than the plan you outlined, but >> given the few fire drills we had recently, it seems better to err on the >> cautious side. >> >> Also, do you know if more removals are planned on your side? It seems >> like it'd be better to "bundle" them so that library authors only have to >> "respin" their deployment once, rather than every few milestones. >> >> >> On Thu, Feb 16, 2023 at 3:10 PM Henrik Boström <h...@chromium.org> wrote: >> >>> *This deprecation is not to be confused with the track stats deprecation >>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/NZVXsJQ7tV8>, which >>> is deprecating a small subset of the modern API. This deprecation related >>> to the removal of the legacy API, a different API with the same name.* >>> >>> *Contact emails* >>> h...@chromium.org, h...@chromium.org >>> >>> *Specification* >>> The legacy getStats() API has no spec, no official documentation and no >>> web platform tests. >>> >>> The modern (promise-based) version of getStats() does have a spec, but >>> this is a different method returning different stats objects: >>> https://w3c.github.io/webrtc-stats/ >>> >>> There are lots of similarities between the modern and legacy APIs, >>> including several metrics that are the same, but the stats report structure >>> is different and the legacy API contains several "goog"-prefixed metrics or >>> metrics that behave differently from the modern API. >>> >>> In 2019, a document was created outlining the differences between the >>> legacy and modern API >>> <https://docs.google.com/document/d/1z-D4SngG36WPiMuRvWeTMN7mWQXrf1XKZwVl3Nf1BIE/edit?usp=sharing> >>> which >>> may still be a useful resource, but for latest information we refer to the >>> modern API's spec <https://w3c.github.io/webrtc-stats/> and code search >>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/api/stats/rtcstats_objects.h> >>> . >>> >>> *Summary* >>> WebRTC is a set of JavaScript APIs (spec >>> <https://w3c.github.io/webrtc-pc/>) enabling real-time communication, >>> most notably realtime audio and video for Video Conferencing in the >>> browser. getStats() is an API that allow apps to measure things like >>> bitrate and media quality information about the session. >>> >>> The history is that spec and implementations evolved so quickly that the >>> API was forked into two paths: the callback-based one that only exists in >>> Chromium and has no spec and the promise-based one which has both a spec >>> and pretty good cross-browser compatibility support >>> <https://wpt.fyi/results/webrtc-stats/supported-stats.https.html?label=experimental&label=master&aligned> >>> . >>> >>> In Chromium, the legacy API has been on feature freeze for several years >>> and the goal was always to deprecate and remove it, but due to high usage >>> this was not a possibility. This story is finally changing: usage graphs >>> <https://webrtchacks.github.io/chromestatus/?buckets=1058,1476,1402&start=2022-01-01&window=7> >>> . >>> >>> [image: Screenshot 2023-02-16 at 13.43.40.png] >>> >>> According to chromestatus.com stats >>> <https://chromestatus.com/metrics/feature/popularity>, >>> - RTCPeerConnectionGetStatsLegacyNonCompliant is 0.0183% and >>> - RTCPeerConnectionGetStats is 0.2177% of page loads. >>> In other words, legacy is 8% as popular as modern. >>> >>> According to UMA stats, >>> - RTCPeerConnectionGetStatsLegacyNonCompliant is 0.000177% and >>> - RTCPeerConnectionGetStats is 0.00114% of page loads. >>> In other words, legacy is 15% as popular as modern. >>> >>> I don't know why UMAs and chromestatus shows different orders of >>> magnitude when it comes to usage, but we're roughly talking about the >>> legacy API being 1/10th as popular as the modern API. I think it is time to >>> add a deprecation warning to the legacy API. >>> >>> *Risks* >>> Usage is still high and migrating from the legacy API to the modern API >>> may require a significant amount of work from developers. >>> >>> To mitigate this, we should have a long deprecation timeline and allow >>> developers to opt-in to a Deprecation Trial to get more time. >>> >>> *Proposal* >>> Add a deprecation warning in M113 and the possibility to opt-in to a >>> deprecation trial. >>> Add use counts for how many of the legacy API uses do and do not use the >>> deprecation trial and track this over time. >>> >>> In M114, start throwing an exception in Canary/Beta if attempting to use >>> the legacy API outside the trial *but do not throw* in Stable yet. Give >>> apps more time to sign up to the trial. >>> >>> In M115, gently roll out the throwing of the exception to Stable, i.e. >>> from this milestone onwards apps are required to use the deprecation trial >>> if they want to continue to use the legacy getStats() API. >>> >>> M115 is Stable on June 27. >>> Set the Deprecation Trial end date to M120 / December 5, 2023. >>> This gives apps paying attention to the deprecation warning ~9 months to >>> migrate and apps only paying attention to exceptions on stable ~6 months to >>> migrate. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to blink-dev+unsubscr...@chromium.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8edb3ad3-c383-4c18-9595-81fb0732fa10n%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8edb3ad3-c383-4c18-9595-81fb0732fa10n%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVD23EvX8b_BBq6PeED%2BrTt0sumgCtG6L%3DWW%2B6Rte3KMw%40mail.gmail.com.
