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

On Thu, Jun 18, 2015 at 3:53 PM, Jan-Ivar Bruaroey <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> 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.



> 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.

-Ekr