- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Thu, 09 Jan 2014 10:04:23 +0100
- To: public-media-capture@w3.org
On 01/09/2014 09:20 AM, Jan-Ivar Bruaroey wrote:
> On 1/8/14 8:18 PM, Silvia Pfeiffer wrote:
>> On Thu, Jan 9, 2014 at 9:33 AM, Jan-Ivar Bruaroey <jib@mozilla.com>
>> wrote:
>>> You're missing my question. Who needs SDP line numbers other than for
>>> debugging? What software needs this information?
>> If I was told which line of SDP produced problems, then I can change
>> that line programmatically and fix up a broken connection attempt. Why
>> would that not be desirable?
>
> Wouldn't you need more than a line-number to pull off something like
> that? Parse the SDP line, scan error message for clues about which
> failure occurred. If you're comfortable parsing SDP and the multitude
> of variations you'll no doubt encounter there, then parsing the error
> message for the line number as well seems like peanuts comparatively.
>
> I don't think we need to deviate from DOMError to make this highly
> advanced kludging marginally simpler. Lets make simple things simple
> and advanced things possible.
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"?
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.
I don't want to encourage that kind of code. If the people who want SDP
line numbers are willing to say "this is only for debugging", I'll go
along with "put it inside the message".
If not - not.
Received on Thursday, 9 January 2014 09:04:47 UTC