Re: New version of editors draft released (20121212)

I read my own mail a second time and realized that it was rather 
confusing. I'll add some text to try to make it more understandable 
(even to me).

On 2012-12-17 10:27, Adam Bergkvist wrote:
> On 2012-12-14 14:27, Dan Burnett wrote:
>>
>> On Dec 14, 2012, at 4:41 AM, Adam Bergkvist wrote:
>>
>
>>> On 2012-12-13 14:59, Dan Burnett wrote:
>>>> I agree that we decided to add "id".  I don't agree with
>>>> removing "label".  My understanding from the f2f meeting was that
>>>> we would end up with both MediaStream and MediaStreamTrack
>>>> objects having both "id" (machine-generated) and "label"
>>>> (human-generated) attributes.
>>>
>>> I remember us talking about the confusing regarding label meaning
>>> something on MediaStream and something else on MediaStramTrack, but
>>> I don't really recall the exact resolution.
>>>
>>> This edit was really a rename of what you refer to as the
>>> "machine-generated" identifier from "label" to "id" to align with
>>> MediaStreamTrack. We've never had a "human-generated" identifier on
>>> MediaStream so it hasn't been removed. :)
>>>
>>> I'm not really convinced we need a human settable identifier on
>>> MediaStream unless it's transported over a p2p connection (and we
>>> have a use-case for that). If you want to assign a custom label to
>>> a MediaStream on the local side you can simply add as many new
>>> properties to it as you like (myStream.label = "Web Cam & headset
>>> mic"; ).
>>
>> As long as MediaStream and MediaStreamTrack have the same (one or
>> two) attributes, I'm happy.  I don't see any more need for a
>> human-generated label on a MediaStreamTrack than on a MediaStream, by
>> your argument above, and yet I believe we are keeping label on
>> MediaStreamTrack.  They should be consistent.

I agree with what you're saying about a human settable version of label. 
It doesn't give us anything that can't be signaled in JS anyhow (attach 
stream/track id to whatever info).

The label attribute we have on track today (UA generated, human 
readable) provides information from the platform about the device that's 
feeding the track with media data. This motivates label on track-level 
since this info can't be retrieved elsewhere.

In the reminder of this mail I'll talk about a similar label for streams 
(i.e. UA generated, human readable).

> As Martin pointed out in an other mail, it may be the wording
> "human-generated" that is part of the confusion here. Both label and id
> are generated by the UA (on track), but one is nicer to read for a
> humans (label: "USB Camera 1" comared to id: 124a1ea42ae4...)
>
> I don't have anything against a label on MediaStream-level, I just don't
> know what it should say. A track represents one device, so in that case
> the label can describe the device. A stream, on the other hand, may
> represent everything from zero to n devices. What should the label be
> there? Should it change if more tracks are added to the stream?
>
> In my reasoning above, I'm still talking about a label of the kind that
> track has: UA generated, but human readable. Is that what you mean as
> well or do you mean really human generated (i.e. not readonly)?
>
> Regarding consistency with one or two properties, I don't think we need
> to have the same attributes describing streams and tracks since they
> represent totally different things. A label attribute on both levels may
> even be more confusing since they can't mean the same thing.
>
> /Adam
>

Received on Monday, 17 December 2012 10:27:16 UTC