- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Tue, 1 Dec 2015 10:03:25 +0000
- To: Peter Thatcher <pthatcher@google.com>
- CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
Anyone else that has input on this matter? Otherwise, I'll go ahead and create an github issue. /Adam On 2015-11-24 09:34, Adam Bergkvist wrote: > I wouldn't mind going down the path of #3 since it would indeed simplify > things to get rid of the double events. I wonder how much code we would > break (besides browser layout tests). > > /Adam > > On 2015-11-23 23:18, Peter Thatcher wrote: >> I like #3. It simplifies. The JS can get to the information it needs >> and doesn't need it to be duplicated in a complex way. >> >> On Tue, Nov 17, 2015 at 2:18 AM, Adam Bergkvist >> <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>> wrote: >> >> Hi >> >> We have some inconsistencies in the spec regarding the active state. >> >> We define active in terms of the stream's track set. In short, if a >> non-ended track exists, the stream is active, otherwise inactive. >> >> The active attribute is specified to return true if the stream is active >> and false otherwise. >> >> We also specify that when a stream goes from active, to inactive, the >> active attribute should be updated to true and the event fired. This >> contradicts the other text that defines the attribute in terms of the >> stream's track set. >> >> Possible solutions: >> >> 1. Just remove the attribute updating part of the event dispatching >> steps. >> >> Since the events are scheduled and fired as a result of sync API calls, >> we might en up in a situation that an "active" event is fired, but >> that's not true (anymore). >> >> 2. Remove the attribute updating part of the event dispatching and use a >> activitychanged event instead of specific active/inactive events. >> >> This way when a scheduled event fires, the script needs to check the >> attribute manually and react. We never get the "event type" - "attribute >> value" mismatch. >> >> 3. Remove the active/inactive events all together. >> >> These events are rather unnecessary. They either follow direct >> manipulation from the script or some other event when the UA has >> initiated a the result of a change to a stream's track set. For example >> the add/removetrack events or MediaStreamTrack ended. >> >> /Adam >> >> > > >
Received on Tuesday, 1 December 2015 10:03:59 UTC