- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Thu, 18 Jun 2015 22:40:13 +0200
- To: public-webrtc@w3.org
- Message-ID: <55832CAD.8030403@alvestrand.no>
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.
Received on Thursday, 18 June 2015 20:40:45 UTC