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?

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