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

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