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

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