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: Mon, 8 Jun 2015 19:13:58 -0700
Message-ID: <CABcZeBOKNdeFOGrAuQPZOUDOAirq5wm0eu3mq-aJ6HuBWvjW_g@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 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?

-Ekr
Received on Tuesday, 9 June 2015 02:15:15 UTC

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