- From: guidou via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Dec 2023 13:40:50 +0000
- To: public-webrtc-logs@w3.org
> > > In general, the value of an "event" is its intent, that something external happened. Therefore, synthesizing events reactively from symptoms seems a mistake. > > > > > > What can the user agent do on platforms where they get no advanced knowledge that frames will not be forthcoming? > > We define APIs based on developer needs, not user agent needs. > I don't think user agents have needs other than the ones of their users (including developers). > If the OS mutes, the user agent owns the problem of detecting that and conveying that as an "event" that happened. E.g. If the user agent has reason to believe lack of frames is instead due to an error, then ending the track may be more appropriate. > To me all this sounds a lot like synthesizing events reactively from symptoms. > The spec already defines muted and ended as separate events for this reason. Agreeing on these definitions is what we've committed to to having browsers interoperate. Yes. Chromium implements both according to the spec. What we're discussing here is how to change the spec to solve new problems (e.g., multiple mute) in a way that doesn't introduce unsurmountable compatibility problems for existing applications. > > > > > the change is about stopping to fire mute events in odd cases. How do you expect it to break existing websites? > > An answer to this question would be helpful. Already answered in a previous message. -- GitHub Notification of comment by guidou Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/982#issuecomment-1853939476 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 13 December 2023 13:40:52 UTC