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

A few people have remarked to me that they did not see this declaration
of consensus
from the chairs on the getParameters/setParameters issue on June 17.

Looking at the list archive, I believe I should have changed the subject
to make it clear that the message contained a declaration of consensus.

We'll try to do better.

Harald

On 06/18/2015 10:40 PM, Harald Alvestrand wrote:
> 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.


-- 
Surveillance is pervasive. Go Dark.