W3C home > Mailing lists > Public > public-media-capture@w3.org > January 2014

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 09 Jan 2014 16:11:34 +0100
Message-ID: <52CEBC26.9060203@alvestrand.no>
To: public-media-capture@w3.org
On 01/09/2014 04:04 PM, Jan-Ivar Bruaroey wrote:
> On 1/9/14 4:04 AM, Harald Alvestrand wrote:
>> So you're suggesting that the SDP line number should be replaced with 
>> a statement "we RECOMMEND that the informative debug message gives 
>> the line number in the SDP where the error occured"?
> Yes, I think that covers typical use just great.
>> It's an informative message. I'll strongly recommend against placing 
>> more restrictions than that on the format.
>> If the line number really is needed by programs, the result will be 
>> code like:
>> if (chrome & chrome-version < 3.44) {
>>    match /SDP line number: \d+
>> } else if (chrome & chrome-version < 4.48) {
>>    match /Description line \d+ contains/
>> } else if (firefox & version >  3.27) {
>>    match /SDP line: \d+/
>> }
>> and so on and so forth.
> It's not needed by programs, except programs that would need to do 
> this anyway IMHO. I think we let this cat out of the bag when we said 
> "SDP parsing" was an API. It's not. It's an emergency access panel to 
> the implementation.

To which viewpoint I agree.....

> My point was quite specific: Line-number isn't enough to cover 
> Sylvia's rather ambitious code anyway, which likely would look like 
> this already to parse the error messages for clues, not to mention 
> browser-specific SDP tricks that might need to be dealt with, so this 
> seems par for the course. Who needs a silver spoon to eat out of 
> trashcans?

But SDP, for all its faults, has a specified grammar. So an SDP parser 
can parse any compliant SDP, and "line number" has a specific meaning. 
No browser implementor governs the syntax of SDP.

My objection above is to encouraging browser-version-specific code.
Received on Thursday, 9 January 2014 15:11:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:23 UTC