- From: guest271314 via GitHub <sysbot+gh@w3.org>
- Date: Tue, 24 Mar 2020 02:13:48 +0000
- To: public-webrtc-logs@w3.org
> I think it's fair to assume that when an OS temporarily suspends everything, all system state halts, and resumes later. That depends entirely on how the user has configured the machine and OS. A user could decide to close the lid on a laptop and expect the running program to continue, because they have set the appropriate values at machine and/or OS level to do just that. `cron` jobs which launch GUI and headless browsers to continue computing; perform tasks when human interaction is not necessary; do not want or need any one else, or self, seeing what data is being processed by the browser, OS, machine on a screen or terminal. `mute`, `unmute`, and `ended` events are currently not consistent between implementations. Implementers are, or shouldd be aware of the inconsistency with regard to the above-listed events at browsers, yet have not fixed those issues to at least be consistent, yet nonetheless will now embark on a path to define what to do "when a machine suspends" which is a very broad term. There is no possible way to determine precisely how all handhelds, laptops, or desktops are configured re "suspend", "hibernate", etc. other than to test each device individually to determine the means by which "suspends" occurs and un-"suspends". What is the compelling need for Media Capture and Streams to delve into where a machine - not just the browser where a `MediaStream` and `MediaStreamTrack` are being used - is "suspended"? Would not a more concrete project be to at least work to make the `mute`, `unmute`, and `ended` events of the various extensions of `MediaStreamTrack` truly compatible and consistent? -- GitHub Notification of comment by guest271314 Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/668#issuecomment-602966968 using your GitHub account
Received on Tuesday, 24 March 2020 02:13:50 UTC