- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Mon, 11 Dec 2023 20:47:21 +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. 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. If the user agent cannot tell whether the OS muted it or whether there was an error, that is its problem to solve. Punting hard questions like this to the webapp doesn't seem reasonable to me. 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. > > > 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. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/982#issuecomment-1850863041 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 11 December 2023 20:47:24 UTC