- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Wed, 23 Sep 2015 09:46:04 +0000
- To: Harald Alvestrand <harald@alvestrand.no>, Jan-Ivar Bruaroey <jib@mozilla.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Reading back on this discussion I note: - discussion on why RTCIceCandidate is not a dictionary, but it seems to become one with [1] - arguments that if we have "fail on malformed" when constructing we should have it on addIceCandidate as well - but I don't think we have a check when constructing So I think it makes sense to merge [2]. Anyone disagreeing? Stefan [1] https://github.com/w3c/webrtc-pc/pull/302 [2] https://github.com/w3c/webrtc-pc/pull/242 On 17/07/15 10:22, Harald Alvestrand wrote: > On 07/16/2015 05:27 PM, Jan-Ivar Bruaroey wrote: >> On 7/15/15 5:03 AM, Harald Alvestrand wrote: >>>> 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. >> >> Good point. Not to advocate change, but just for info, what was the >> rationale for RTCIceCandidate not just being a dictionary? > > Speaking from memory.... > > when RTCIceCandidate and RTCSessionDescription were added to the spec, > we felt that having these as interfaces would allow us to provide them > with accessors and manipulators at a later stage (one could imagine > having RTCIceCandidate having a "syntacticallyValid" attribute, for > instance). > > This was before we started falling in love with dictionaries. Many moons > ago.... > > > >
Received on Wednesday, 23 September 2015 09:46:31 UTC