On Thursday, February 23, 2023 at 11:03:44 AM UTC+1 Yoav Weiss wrote:
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? If they notice the deprecation warning they would have enough time to migrate before the Deprecation Trial is even needed. If they don't, how about 3 months extra? 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/54f01091-f7a9-4d4a-b4ee-d882b5d79565n%40chromium.org.
