Re: MediaError object (Re: New Editor's draft v20131225)

On 01/08/2014 10:31 PM, Jan-Ivar Bruaroey wrote:
> On 1/8/14 1:27 PM, Harald Alvestrand wrote:
>> On 01/08/2014 06:49 PM, Jan-Ivar Bruaroey wrote:
>>> Lets look at the design of the construct we proclaim to be using. 
>>> DOMError covers all of DOM with 21 names without even a 
>>> message-field (I hear they're adding one, bully for us), then we 
>>> come along and add a third property we'll only use with one name, in 
>>> half of one controversial API, for slippery slope reasons? That 
>>> seems antithetical to the design to me, a DOMErrorino (DOMError in 
>>> name only), except we wont have the actual name either.
>>>
>>> I propose we drop the constraintName property unless use-cases can 
>>> be shown that need it.
>>
>> The constraintName property (and the sdpLineNumber property in the 
>> WebRTC draft) were added for reasons that seemed good at the time; 
>> you can't indicate a line number with an error code.
>
> But you can in a message-field, which I understand DOMError will grow. 
> Why is that not sufficient?
Because that means you can only get it out via parsing the text of the 
field, which means that the format of the text message is part of your 
API, cannot be allowed to vary between implementations, and has to be 
specified in your specifications.

That's a rather unstructured form of API.

(IMAP, when faced with a similar problem, put stuff that clients should 
parse into square brackets, and the rest of the human-readable message 
outside them. That's a suitable thing for an ASCII protocol; it seems 
like a weird thing to do when already handling structured objects.)