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

This sounds good to me.

I've filed https://github.com/w3c/mediacapture-main/issues/164 to keep
track of the issue.

Den 22. april 2015 12:04, skrev Adam Bergkvist:
> On 2015-04-22 11:41, Harald Alvestrand wrote:
>> 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).
> 
> I don't think it's an issue. We need to specify what happens if, for 
> example, getCapabilities() is called on a track with a stopped source. 
> But it's not a new problem; detached or stopped, I guess the same thing 
> should happen.
> 
>> We do have the concept of a source ending by itself (someone removed the
>> camera?), which causes all the attached tracks to stop.
> 
> It's mentioned in the MediaStreamTrack.onended handler [1].
> 
> [1] https://w3c.github.io/mediacapture-main/#widl-MediaStreamTrack-onended
> 
> 
>

Received on Wednesday, 22 April 2015 12:10:15 UTC