Re: pc.localDescription sync/async issue

Turns out I misread our code a bit, we only cache the "type". I'm less 
concerned about this so I'm happy to leave it alone. I understand a lot 
went into this piece.

.: Jan-Ivar :.

On 12/12/14, 2:24 PM, Jan-Ivar Bruaroey wrote:
> I just found out that - in our implementation - users can read 
> pc.localDescription synchronously right after having called 
> setLocalDescription and get the result they are in the process of 
> setting, even before it has finished (!)
>
> This seems quite wrong - especially if setLocalDescription were to 
> fail - but I'm not confident it's not a spec issue.
>
> Confusingly, the spec in http://w3c.github.io/webrtc-pc/#attributes says:
>
> "The localDescription attribute MUST return the RTCSessionDescription 
> that was most recently passed to setLocalDescription(), plus any local 
> candidates that have been generated by the ICE Agent since then."
>
> Since setLocalDescription() is asynchronous, this is ambiguous. Could 
> this be worded better with regard to what it should return when 
> setLocalDescription has been called but its callbacks haven't been?
>
> Hopefully it's uncontentious that it should return null or any 
> previous description if there is one.
>
> .: Jan-Ivar :.

Received on Friday, 12 December 2014 19:56:56 UTC