RE: New version of editors draft released (20121212)

What happened to section 4.6 on error handling?  I know that you thought some of it was redundant, but it seems to have disappeared altogether. 

- Jim

-----Original Message-----
From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com] 
Sent: Monday, December 17, 2012 5:27 AM
To: Dan Burnett
Cc: public-webrtc@w3.org
Subject: 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 14:58:05 UTC