LGTM2, even better!
On Fri, Feb 24, 2023 at 5:04 PM Yoav Weiss <yoavwe...@chromium.org> wrote:
SGTM!
On Fri, Feb 24, 2023 at 4:40 PM Henrik Boström <h...@google.com>
wrote:
Yes, I think throwing in M117, stable on Aug 30 would be even
better.
On Friday, February 24, 2023 at 4:32:21 PM UTC+1 Philip
Jägenstedt wrote:
I think the overall timeline looks great, the final
removal is almost a year from now, after the 2023 holiday
season.
However, I'd like to bikeshed "Throw an exception if the
trial is not used in Stable in M119 (Release: October 31,
2023)". This is when the breakage will be apparent to most
users/developers, anyone who isn't paying attention to
deprecation warnings. Oct 31 doesn't give a whole lot of
time to figure out how origin trials work and opt into
that, so I would suggest M117, stable on Aug 30. That's as
early as seems reasonable given summer vacations in the
northern hemisphere.
WDYT Henrik, would that work just as well for you?
On Thu, Feb 23, 2023 at 1:17 PM Yoav Weiss
<yoav...@chromium.org> wrote:
LGTM1 for that plan
On Thu, Feb 23, 2023 at 12:48 PM Henrik Boström
<hb...@chromium.org> wrote:
In that case the proposal is:
- Add deprecation warning in M113 (Release: May 2,
2023) with the possibility to opt-in to the
Deprecation Trial.
- Throw an exception if the trial is not used in
Canary/Dev/Beta in M114.
- Throw an exception if the trial is not used in
Stable in M119 (Release: October 31, 2023).
- Let M121 be the last version where the Trial is
available (Release: January 9, 2024). In other
words the first version where the trial and legacy
getStats API is entirely removed is M122 (Release:
February 6, 2024).
On Thursday, February 23, 2023 at 11:38:48 AM
UTC+1 Yoav Weiss wrote:
SGTM
On Thu, Feb 23, 2023 at 11:34 AM Henrik
Boström <hb...@chromium.org> wrote:
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 <hb...@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 and +Andre Bandarra 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
<hb...@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*
hb...@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/
<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>.
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+...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXvoddJYizkHGzmavf6LLyqxY1VGLfZfW%3D%2BrmZBBHNq8Q%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXvoddJYizkHGzmavf6LLyqxY1VGLfZfW%3D%2BrmZBBHNq8Q%40mail.gmail.com?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/CAARdPYfRn4nBRmfmvgJ8DFnmEZaCN_fGxqkEGsYK9z2ndyL1fQ%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfRn4nBRmfmvgJ8DFnmEZaCN_fGxqkEGsYK9z2ndyL1fQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
