Hi Blink API Owners,
I am preparing to ship the Web Audio Playout Statistics API (Chrome Status:
https://chromestatus.com/feature/5172818344148992). Following recent specification updates to align with standardized terminology, I am renaming the API surface and have a few process-related questions:
1. Chrome Status Title Update: Is it acceptable to simply rename the existing Chrome Status entry from "AudioContext.playoutStats" to "AudioContext.playbackStats"? The underlying functionality is unchanged, but the interface/prop name has shifted to match the spec.
2. To ensure zero breakage for the primary partner of the experimental implementation and to maintain UMA continuity, my current implementation exposes both the old and new API shapes simultaneously (only up to M146):
- AudioContext.playbackStats (New) and .playoutStats (Legacy alias).
- AudioPlaybackStats interface with [LegacyWindowAlias=AudioPlayoutStats].
- Properties like underrunDuration (New) and fallbackFramesDuration (Legacy alias via [ImplementedAs]).
- toJSON() output includes a superset of both new and legacy keys.
Do the API Owners have any concerns with shipping this "superset" approach for a transitional period (M146) to facilitate a non-breaking migration?
3. Intent to Ship UI: I am currently in the "Prepare to Ship" stage on Chrome Status, but I do not see the "Draft Intent to Ship email" generation button. Is there a specific prerequisite I might be missing, or should I proceed with a manual draft for blink-dev?
Thanks for your guidnace.