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

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 09 Jun 2015 13:18:47 +0200
Message-ID: <5576CB97.30802@alvestrand.no>
To: public-webrtc@w3.org
Den 09. juni 2015 03:24, skrev Jan-Ivar Bruaroey:
> 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.

Actually I agree with Jan-Ivar about the model, but I think Jan-Ivar is
still wrong about his conclusion.

consider 2 properties x and y with possible values "a" and "b", where
the combination "aa" is illegal.

In the code:

  (precondition: x=b, y=a)
  t.x = a
  t.y = b

the first assignment will lead us to an illegal state. This does not
matter to the underlying subsystem (says Javascript), because we're
going to get to a legal state on the next line. No error occurs.

But in the code

  (precondition: x=b, y=a)
  t.x =a

we WILL be in an illegal state at the end of this piece of Javascript.
But where does the error occur? When does it make sense to report an error?

Not when setting x - we don't know that it's going to cause trouble yet.
Not at the end of execution - there is no handler there.
The only possible way I can see is an out-of-the-blue event that occurs
after the end of execution, saying "You goofed at some previous point in
time".

I like the model

  p = t.args() // returns ba
  p.x = a
  p.y = b
  t.set(p)

because it makes it obvious to the programmer when his parameters are
going to be checked, and exactly which statement is going to error out
(or, if checking has to occur asynchronously, which statement returns a
promise that might be rejected).

Clearer for the programmer. He's high in our hierarchy of constituencies.
Received on Tuesday, 9 June 2015 11:19:18 UTC

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