W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2015

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

From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 18 Jun 2015 23:11:51 -0400
Message-ID: <CABcZeBNXe4O=j949Y6eda_5zwegW5-Purz7c4JC=KnQUnmfy1g@mail.gmail.com>
To: Jan-Ivar Bruaroey <jib@mozilla.com>
Cc: Peter Thatcher <pthatcher@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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

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

Received on Friday, 19 June 2015 03:13:12 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:44 UTC