Re: RtpSender.getParameters and RtpSender.setParameters vs. RtpSender.param1, RtpSender.param2, ...

On 6/8/15 10:13 PM, Eric Rescorla wrote:
> On Mon, Jun 8, 2015 at 6:24 PM, Jan-Ivar Bruaroey <jib@mozilla.com 
> <mailto:jib@mozilla.com>> wrote:
>
>     On 6/8/15 7:01 PM, Peter Thatcher wrote:
>>     ... setting them individually just doesn't make sense because the
>>     time between setting them would cause the RtpSender to be in an
>>     invalid, broken, or awkward state.
>
>     Sorry to disagree, but the "time between setting them" will
>     /*not*/ do that.
>
>     It isn't possible, because RtpSender is *not allowed* to
>     observably progress in that time, /because JS is a single-threaded
>     model/.
>
>     Like it or not, this is why we queue a task for everything: to
>     keep JS in the dark about anything happening in parallel to its
>     execution
>
>     RtpSender is not above this law, and must queue a task before
>     altering any of its properties in response to time.
>
>
> But we've already established that this isn't true with respect to 
> time, so it's not clear to
> me that this is in fact an invariant. Can you please point to a 
> specification requirement
> (i.e. not an experiment) that supports your argument that changes to 
> RtpSender cannot
> have observable side effects before we return to a JS stable state?

Sorry for the delay in answering this good question. I've learned that 
while these realities are not formalized as spec requirements anywhere, 
the Tag is working on guidelines to enshrine design principles around 
WebAPIs, that include preserving the run-to-completion semantics of 
JavaScript (basically that any data observed within the function will 
stay constant as long as that function is active).

I hope that answers the question.

.: Jan-Ivar :.