Re: Attributes! (Re: Proposal: Add RtpSenderInit parameter to addTrack.)

On 5/1/15 1:43 PM, Peter Thatcher wrote:
> I'll repeat some text I wrote previously about replaceTrack:
>
>
> In the work in the ORTC CG, we chose to follow the .setFoo pattern 
> rather than the .foo= for all things, not just setTrack for the 
> following reasons:
>
> 1.  It allows return values, async and sync.  You might think you 
> don't want one now, but you might want to add one later.
> 2.  It allows async errors.
> 3.  It allows for adding additional parameters.  You might think you 
> don't want one now, but you might want to add one later.

Is "you" the implementer? If so, then I think this violates the priority 
of constituencies. [1]

> Specifically, in your example:
>
>   var fooParameters = foo.getParameters();
> fooParameters.bar = "big";
> fooParameters.fum = " deal";
> foo.setParameters(fooParameters)
>
> That's exactly the situation we want to encourage, because it allows 
> and encourages the setting of parameters to be atomic.  Doing 
> something like this is madness:
>
> foo.parameters.bar = "big";
> foo.parameters.fum = " deal";
>
> Because then you have all this half-set stuff and you have to reason 
> about what those things mean when half-set.

To be clear, we're talking about implicit action from changing a 
grab-bag of /discrete/ settings, not splitting atoms.

This is not multi-threaded c++ where how long to wait to respond to a 
bag of discrete changes is tricky. JavaScript is event-driven:

     var foo = {};
     Promise.resolve(() => log(foo.bar + foo.fum); // ALWAYS emits "big 
deal"!
     foo.bar = "big";
     foo.fum = " deal";

which means there's a quite valuable inherent end to any set of 
sequential actions: the completion of the current task. Any update or 
refresh task need only be scheduled after the end of the current task to 
solve all "half-set" problems.

I see no need to coerce discrete changes into atomic bundles (pardon the 
oxymoron) in such a model.

> Finally, I don't think it makes sense to have RtpParameters and 
> RtpSenderInit be the same class because there are certain arguments 
> which can change (stuff in RtpParameters) and certain arguments which 
> can't change (label).  If we put label, for example, into 
> RtpParameters, that would imply that it can change via setParameters.  
> On the other hand, if we either want other things in RtpParameters to 
> be unchangable or if we have no things we want to have be unchangable 
> (we remove the ability to set the label, for example), then 
> RtpParameters could be the same class as RtpSenderInit.

You misunderstand, I want to replace RtpParameters with attributes on 
RtpSender. E.g.

- label would exist as a member in RtpSenderInit and as a readonly 
attribute on RtpSender.
- voiceActivityDetection would exist as a member in RtpSenderInit and as 
an attribute on RtpSender.

Just like everywhere else the InitDict pattern is used.

.: Jan-Ivar :.

[1] http://www.w3.org/TR/html-design-principles/#priority-of-constituencies