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

That is true.

But then the choice moves from one between separate attributes and get/set
methods to one between one "big" attribute and get/set methods, which is
very similar to the choice between settable .track vs. .replaceTrack.
 That ended up falling on the side of a method rather than an attribute,
and I think a method would be better than an attribute for most of the same
reasons.



On Mon, Jun 8, 2015 at 4:17 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

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