Re: Possible simplification: Remove distinction between track "stop" and source "detach"

Den 22. april 2015 11:31, skrev Adam Bergkvist:
> On 2015-04-15 15:11, Harald Alvestrand wrote:
>> In the current specification, we have two concepts related to sources
>> and tracks:
>>
>> - A track can be stop()ed, in which case it is ended.
>> - A track can be detached from its source.
>>
>> The text says:
>>
>> A) in terminology for "source", we have:
>>
>> Sources are detached from a track when the track is ended for any reason.
>>
>> B) Under "Life-cycle and Media Flow", we have:
>>
>> A MediaStreamTrack can be detached from its source. It means that the
>> track is no longer dependent on the source for media data. If no other
>> MediaStreamTrack is using the same source, the source will be stopped.
>> MediaStreamTrack attributes such as kind and label must not change
>> values when the source is detached.
>>
>> C) Under the "enabled" attribute of a track, we have:
>>
>> On getting, the attribute must return the value to which it was last
>> set. On setting, it must be set to the new value, regardless of whether
>> the MediaStreamTrack object has been detached from its source or not.
>>
>> Under the "stop" function for a track, we have:
>>
>> 3. Set track's readyState attribute to ended.
>>
>> 4. Detach track's source.
>>
>> It seems to me that this is one concept more than we need.
>> Whether there is a relationship between a stopped track and its source
>> or not is an implementation detail, and we shouldn't be constraining it
>> in our API description.
>>
>> So my suggestion:
>>
>> In A, C and D, simply remove the text that refers to "Detach".
>>
>> In B, instead say:
>>
>> If all MediaStreamTracks that are using the same source are ended, the
>> source will be stopped.
>>
>> I think that simplifies the terminology, and doesn't change any
>> observable property of the API.
>>
>> What do people think?
>> (If others like it, I'll file a bug for it.)
> 
> I think this is a simplification worth doing.
> 
> This will let us refer to properties on the source without having to 
> verify that the track has a source attached. A new thing, however, is 
> that a track can have a stopped source (attached).

Is this an issue?

I think only stopped tracks can have stopped sources, since a source is
only stopped if all the tracks have been stopped. So we can't have a
live track sourced from a stopped source (which would indeed be a bit
strange).

We do have the concept of a source ending by itself (someone removed the
camera?), which causes all the attached tracks to stop.

Received on Wednesday, 22 April 2015 09:42:00 UTC