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

On 6/9/15 7:18 AM, Harald Alvestrand wrote:
> 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.

This is the discussion I wanted to get to, now that we see concurrency 
is not an issue.

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

This is a good observation, that we can't generally throw on assignment 
in this model. We would need an error event on the sender.

Whether t.onerror is a good idea or not may depend on whether a sender 
can fail for reasons unrelated to a request from JS. If a sender may 
fail at any time due to e.g. a network error, then maybe this makes 
sense. If it can only fail from JS modification, then maybe not so much.

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

It would be a synchronous event fired when the attributes are 
collectively read on the next cycle.

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

Compare to:

   t.x = a
   t.y = b
   t.onerror(e => { throw e })


Not everything has to be an attribute of course. Methods are better for 
some things.

.: Jan-Ivar :.

Received on Thursday, 18 June 2015 20:50:09 UTC