Re: Sort out active state spec inconsistencies

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
> 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
>
>