- From: Cullen Jennings <fluffy@iii.ca>
- Date: Mon, 18 Jun 2012 12:56:23 -0600
- To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Cc: public-webrtc@w3.org
On Jun 18, 2012, at 7:53 AM, Stefan Hakansson LK wrote: > On 06/07/2012 04:29 PM, Harald Alvestrand wrote: >> On 06/07/2012 10:16 AM, Adam Bergkvist wrote: >>> Hi >>> >>> Yes, updateRemoteDescription() needs to be able to handle both. We've >>> talked earlier about letting the functions that feed data down to >>> PeerConnection take a DOMString and let the objects automatically >>> stringify. Then you don't have to wrap the received string in an >>> object unless you're actually need it. >> I am leery of automatic unstringifiers. They make it less clear where >> parse errors get reported. >> >> I also see the sense in unifying the handling for stuff that calls >> setRemoteDescription, but I kind of feel that the ICE candidate update >> comes in another semantic category, and deserves different syntax. > > I think I agree: I like the less verbose syntax for offer/answer Adam proposed, but I think we should keep ICE candidates separate. One reason is that the app would still need to separate them out since ICE messages can be just applied, while for SDP offers/answers glare must be handled by the app. agree with you here ... I feel pretty strongly that ICE Candidates need to be separate things from SDP Offer/Answers.
Received on Monday, 18 June 2012 18:56:49 UTC