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

Note:

As chair:
At the moment we (the chairs) believe that the rough consensus of the
group is to go with the getParameters / setParameters paradigm for
RTPSender parameters.

As contributor:
My personal reason for believing that this pattern is superior for this
use is the better ability to handle sets of parameters that have
interrelationships; others may have other reasons to prefer it.


On 06/18/2015 09:53 PM, Jan-Ivar Bruaroey 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
>> <mailto: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 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.
>
> .: Jan-Ivar :.
>


-- 
Surveillance is pervasive. Go Dark.