W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2013

Re: addIceCandidate behavior

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 01 Nov 2013 06:37:39 +0100
Message-ID: <52733E23.2050103@alvestrand.no>
To: public-webrtc@w3.org
On 10/30/2013 09:59 PM, Adam Roach wrote:
> We've had some implementors express confusion about the behavior that
> addIceCandidate should exhibit. The current spec says this:
>
>> If the candidate parameter is malformed, throw a |SyntaxError|
>> exception and abort these steps.
>>
>> If the candidate is successfully applied, the user agent /MUST/ queue
>> a task to invoke successCallback.
>>
>> If the candidate could not be successfully applied, the user agent
>> /MUST/ queue a task to invoke failureCallback with a |DOMError|
>> object whose |name| attribute has the value TBD.
>>
>
> Given that we're passing in an RTCIceCandidate as the parameter, it's
> not clear to me what "malformed" might mean. Is an RTCIceCandidate
> with a null "candidate" attribute "malformed"? Or is that simply a
> candidate that "could not be successfully applied"? Or, for that
> matter, do we consider processing of an RTCIceCandidate with a null
> candidate attribute to be successful?

Hm. Can we make a guarantee that an RTCIceCandidate always has a
non-malformed "candidate" attribute?

What comes to mind is the case of RTCIceCandidate("Once upon a time...")
- that is, the string used to create it doesn't conform to the candidate
grammar.

Perhaps the description (and the throw) is better applied to
RTCIceCandidate's constructor, so that an RTCIceCandidate is always
known to be syntactically valid?


>
> /a


-- 
Surveillance is pervasive. Go Dark.
Received on Friday, 1 November 2013 05:38:10 UTC

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