- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Mon, 8 Jun 2015 16:17:45 -0700
- To: Peter Thatcher <pthatcher@google.com>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
I'm not necessarily supportive of this notion, but can't you set co-dependent attributes atomically like this: sender.codependentStuff = new RTCCodependentParameters({ a: 1, b: 2, c: 3}); On 8 June 2015 at 16:01, Peter Thatcher <pthatcher@google.com> wrote: > And here is my opinion on the matter: > > While the attribute approach is reasonable for 2 settings which don't have > much interaction between each other (they might be OK for just active and > priority, for example), the model quickly falls apart when there are many > settings that have interactions between each other. > > As we add more and more settings (which are bound to do), we will quickly > run into a situation where it only makes sense to change two settings > simultaneously, and 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. Further, we'll end up in situations > where setting one attribute will fail while previous settings succeeded, and > the sender will end up in a "half set" state. Reasoning through all these > states as we add more and more settings will be far too complex. > > In other words, we're deciding between "set active; set priority; set > futureParam; ..." and "set (activity, priority, futureParam, ...);". For 2 > things, "set; set" isn't so bad. For 10 things, it gets a lot worse. > > > In fact, we already went through this design and discussion for > PeerConnection.setConfiguration (aka updateIce), and came up with this > model: > > var cfg = pc.getConfiguration(); > cfg.iceTransports = "foo"; > cgf.iceTransportPolicy = "bar"; > pc.setConfiguration(cfg); > > Not: > > pc.iceTransports = "foo"; > pc.iceTransportPolicy = "bar"; > > > > Which is exactly the same as: > > var parameters = sender.getParameters(); > parameters.active = true; > parameters.priority = 0.5; > sender.setParameters(parameters); > > Not: > > sender.active = true; > sender.priority = 0.5; > > > In this way, RtpSender.setParameters is better than attributes, just like > PeerConnection.setConfiguration is: it allows state to be set in one call, > atomically, which is much easier to reason about as the number of controls > increases over time. > > On Mon, Jun 8, 2015 at 3:57 PM, Peter Thatcher <pthatcher@google.com> wrote: >> >> Recently, I wrote up a PR reflecting what we (roughly) agreed up on at >> TPAC 2014: https://github.com/w3c/webrtc-pc/pull/234. >> >> In it, I basically added this: >> >> partial interface RtpSender { >> RtpParameters getParameters(); >> void setParameters(RtpParameters parameters); >> } >> >> dictionary RtpParameters { >> // I actually proposed that we put these in an "RtpEncodingParameters", >> // But let's save that for another email thread. >> boolean active; >> double priority; >> // In the future: maybe bitrates, resolutions, framerate, fec, rtx, >> codecs, header extensions, ... >> } >> >> >> But now there is an alternative idea: >> >> partial interface RtpSender { >> boolean active; >> double priority; >> // In the future: maybe bitrates, resolutions, framerate, fec, rtx, >> codecs, header extensions, ... >> } >> >> >> So the question for the list is: which path do we go down? It seems like >> we're stuck until we get some consensus on one way or the other. >> >> >> >> >> >> >> >> >> >> >
Received on Monday, 8 June 2015 23:18:12 UTC