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


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

Received on Thursday, 18 June 2015 20:40:45 UTC