Re: Proposal-ORTC Sender / Receiver Capabilities Based Model

*

I have not suggested removing or hiding parameters in the capabilities 
based model proposal. Both models use parameters and require parameters 
to have detailed and standardized definitions. Most of the work in the 
doc was around making parameters work for SVC beyond geometric.


My real problem is with "filterParameters". It's simply an undefined 
magic black box that does unspecified "negotiation" style stuff by 
messing with parameters based on filtering capabilities. What exactly 
does that method do in detail? I tried to figure it and realized is 
extremely difficult to define what exactly it does, make it work 
predictably well for all use cases, and make it future proof.


Upon reflection, I also realized we don't need it. None of the other 
ORTC objects have this "filtering" concept, but sender/receiver has it. 
So, I asked myself, why? It's enough to get the detailed "params" set-up 
properly with the correct settings based on the capabilities and that's it.


That's why I came up with the capabilities proposal which does 
createParameters" based on capabilities (as is done right now) but does 
not need to filter them after. That's the major difference.


I realized that if "createParameters" operates in a predictable manner 
(which it must anyway), senders and receivers can work just fine without 
ever having to exchange or filter parameters over the wire. Nice 
benefit. Nothing stops the sending the parameters over the wire but 
nothing requires it either. Nothing stops a JS abstraction layer from 
being written to perform some kind of filter/negotiating methodology, 
but it does not need to be part of our ORTC API to work.


I do realize we don't need "createParameters" method at all for that 
matter. It's there for convenience only. In theory, a JS abstraction 
layer could create parameters by just reading the capabilities (if they 
were rich and descriptive enough). We have "createParameters" because we 
want the API to be usable without having to requiring complex parameter 
setup for each and every use case. The current "createParameters" is 
convenient for the most basic use cases only, so I made it to make it 
much more useful for typical use cases. Is it truly needed? No... but 
it's not needed for the simple case either. So, to me, make it do 
something truly useful, or remove it.

*
-Robin

> Justin Uberti <mailto:juberti@google.com>
> May 8, 2014 at 3:58 PM
> I haven't grokked all the details of this proposal yet, but I don't 
> think adding an indirect way of controlling params in the API proper 
> is a good idea. If app developers want to be shielded from complexity, 
> that's what JSL abstractions are for. And it's not clear that we're 
> going to save on complexity by adding yet another config surface.
>
> The idea that different implementations will support different 
> parameters is also scary to me. Part of the reason that WebRTC is 
> valuable is that it enforces a shared set of requirements on all 
> applications. The idea that we might mix and match what needs to be 
> supported seems like a dangerous direction.
>
> Lastly, the advantages/disadvantages section is fairly one-sided; I 
> think any of the things you suggest can be done with the new approach 
> are also possible with the existing approach.