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

On 6/18/15 11:11 PM, Eric Rescorla wrote:
> On Thu, Jun 18, 2015 at 3:53 PM, Jan-Ivar Bruaroey <jib@mozilla.com 
> <mailto:jib@mozilla.com>> wrote:
>
>     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
>
>
> Except that I've shown that they're not realities, at least with 
> regards to time.

I meant the realities that while (hardware) time is observable, scant 
other concurrent data is - on purpose - at least coming out of specs 
that queue a task whenever they update JS on things. The latter seems 
informative here, not the former.

>     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.
>
>
> Not really. If you wish to rely on this, please provide a citation.

It's still "in progress": https://w3ctag.github.io/design-principles/#js-rtc

.: Jan-Ivar :.