- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Mon, 28 Feb 2022 22:22:40 +0000
- To: public-webrtc-logs@w3.org
> I suppose that's the price we pay for having an event fire when we change the state. Yes. We can either: 1. change state synchronously and fire an event later (but when you get the event(s) later, state might differ), or 2. always change the state from inside the queued task firing the event We cannot have both. > The existence of "queue a task" means that the following test snippet: > ``` > generator.muted = true; > assert_true(generator.track.muted) > ``` > will fail. Seems desirable. Any assumption of the opposite would likely fail to consider that this affects *all* track clones from this generator (which can be an unbounded number), even ones transferred to workers (on different threads). While we could make an exception for same-thread tracks, I don't see what that would serve other than feed this assumption. > The double dispatch means that the following test snippet: > ``` > generator.track.onmute = <observer code goes here> > generator.track.onunmute = <observer code goes here> > generator.muted = true; > generator.muted = false; > ``` > will not observe any event (because at the time the first task starts executing, "settledValue" will be false, which is "no change"). This also seems desirable to me. The prose is there to avoid the following firing 1000 events: ```js for (let i = 0; i < 1000; i++) { generator.muted = true; generator.muted = false; } ``` ...because that seems very different from how hardware devices (which tend to run in the background) typically work. As a JS-based plug-in for what's normally a hardware device running in the background, being able to synchronously observe results on MST seems of low value to me (outside of tests). It seems better to me to separate timing of one side from the other. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-transform/issues/81#issuecomment-1054720368 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 28 February 2022 22:22:42 UTC