Re: A proposal for renaming MediaStreamError

On 05/10/2014 07:36 AM, Kiran Kumar Guduru wrote:
> Samsung Enterprise Portal mySingle
>
> Harald,
>
> Thanks for your response.
>
> Please find my comments inline.
>
> ------- *Original Message* -------
>
> *Sender* : Harald Alvestrand<harald@alvestrand.no>
>
> *Date* : May 09, 2014 22:30 (GMT+09:00)
>
> *Title* : Re: A proposal for renaming MediaStreamError
>
> On 05/09/2014 07:33 AM, Kiran Kumar Guduru wrote:
>>
>> Hi,
>>
>> MediaStreamError is fired, whenever an error occured on a 
>> MediaStreamTrack, like
>>
>> overConstrainedError, constraintNotSatisfiedError, NotSupportedError, 
>> PermissionDeniedError,
>>
>> In case of overConstrained,
>>
>> "This error event fires asynchronously for each affected track "
>>
>> So it seems, better to rename MediaStreamError to MediaStreamTrack 
>> error, by adding one more attribute representing MediaStream.
>>
>> interface MediaStreamTrackError {
>>
>> DomString name;
>>
>> DomString message;
>>
>> DomString constraintName;
>>
>> MediaStream stream;
>>
>> }
>>
>
> I don't really want to do this. The main reason why MediaStreamError 
> exists is that we were told it was unwise to inherit from DOMError 
> (the previous "standard error"), so we had to define our own, and the 
> chief reason why it's not called MediaError is that that name is 
> already in use in HTML5.
>
> [KIRAN] In that case, since we are not going to inherit errors from 
> DOMError, I hope we can remove the open issue: "We may make 
> MediaStreamError inherit from DOMError once the definition of DOMError 
> is stable." from the spec.
>
>
> I have doubts about having the (optional) constraint name in there in 
> the genral case, since it's only useful in the case of errors that 
> have something to do with constraints - and there are other error 
> cases to consider - but was convinced that it was easier to do it this 
> way than to define a new class MediaStreamConstraintError for the 
> extension with the constraintName.
>
> [KIRAN] Perhaps I might have missed this discussion.
>

Not surprising, since it was a private conversation with the editor. I 
did not see any objections to the proposal on the list, so I concluded 
that nobody else was apprehensive enough about this to make noise, so I 
did not consider it important to pursue.

>
> If you have an use case that requires a stream to be passed back, I 
> think it would be better to subclass MediaStreamError for that case 
> than to add more error fields to it in all cases. But this may be a 
> matter of (dis)taste.
>
> [KIRAN] I proposed passing mediastream back, thinking some error 
> events similar  to that of doohickey events which may require to 
> specify to which mediastream they belog to. I may come back with the 
> usecase after doing some more thorough analysis.
>

Also note that in all cases where the return is a callback, you can use 
Javascript closures to make available all information that is available 
to the caller of the function that sets up the callback. The use cases I 
can think of offhand where this is relevant all belong on the webrtc 
list, not here.