W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2015

Re: Removing syntaxerror for ice candidates

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 15 Jul 2015 11:03:47 +0200
Message-ID: <55A621F3.9030500@alvestrand.no>
To: public-webrtc@w3.org
Den 15. juli 2015 10:48, skrev Adam Bergkvist:
> On 2015-07-09 12:25, Dominique Hazael-Massieux wrote:
>> On 09/07/2015 12:09, Harald Alvestrand wrote:
>>>> It does fail, but not with a SyntaxError (which is what I'm suggesting
>>>> we remove).
>>>
>>> So you're suggesting we remove the SyntaxError, but continue failing ...
>>> what are you suggesting we use as a failure instead?
>>>
>>> I'm much happier with proposing "change error code X to Y in case W"
>>> than with "remove SytaxError".
>>
>> The spec already has a step failure after the current syntaxerror:
>>     If the candidate parameter is malformed, reject p with SyntaxError and
>>     jump to the step labeled Return.
>>
>>     If the candidate could not be successfully applied, reject p with a
>>     DOMError object whose name attribute has the value TBD
>> http://w3c.github.io/webrtc-pc/#widl-RTCPeerConnection-addIceCandidate-Promise-void--RTCIceCandidate-candidate
>>
>> I don't have a specific probably for what TBD should be; the spec
>> suggests InvalidCandidate and InvalidMidIndex, but that probably needs
>> to be revisited in light of how we now understand errors should be managed.
>>
>> But even if the whole picture is not clear yet, the reasons for removing
>> syntaxerror (not well defined, not implemented, not necessary) still stand.
>>
>> Dom
>>
> 
> If we plan to fail when an RTCIceCandidate is constructed with a bad 
> candidate string, we need to perform the same check every time the 
> corresponding attribute is set.

Yep. Which argues that the RTCIceCandidate should either be immutable or
allow syntactically invalid candidates.

Otherwise, this will work:

c.candidate = part1 + ' ' + part2

but this will not work

c.candidate = part1
c.candidate += ' '
c.candidate += part2

Violates the principle of least surprise.
Received on Wednesday, 15 July 2015 09:04:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:45 UTC