Re: A clarification on Capabilities, Parameters, createParameters, and filterParameters.

[RR] See inline

> Peter Thatcher <mailto:pthatcher@google.com>
> May 9, 2014 at 5:31 PM
> So, you're basically saying you want to:
>
> 1.  Remove filterParameters.
> 2.  Add an extra option to the end of createParameters.
>
> I can sort of understand #1, since it isn't strictly necessary to be 
> in the API.  But I'd like to try implementing and using it first.  It 
> just doesn't sound that hard to me to implement, or to use.  It's 
> basically createParameters while reusing some information from the 
> last time createParameters was run.  And I'm not that worried about 
> "all the use cases", because if doesn't have to work for all use 
> cases.  It just has to work for some simple ones, and that's it.  If 
> it doesn't work for your use case, don't use it.
[RR] I think my understanding of "filterParameters" was/is inconsistent 
with yours. I was under the impression it had to be able to filter 
advanced stuff (like SVC) and not just the bare bones simple stuff. If 
it only filters the basics, I honestly don't think it adds much value 
and I think filtering the complex stuff is a lot harder than it seems 
and requires complex rules and expanded Capability definitions. As it 
stands though, the exact rules of how it operates needs to be defined 
otherwise nobody else can implement this API. Perhaps I'm a thick in the 
skull, but I can't figure out how to make it truly work well for 
anything beyond the most simple, and I also don't think it's very 
"future proof". I would still suggest it's a candidate for elimination. 
We can make the API work for simple use cases without it anyway.
>
> I can also understand #2, as I mentioned before.  But it would need to 
> be very simple, and every time I think of a simple set of options to 
> pass in, I think: why not just do this in a JS library, or learn how 
> to use RtpParameters?  Again, playing with RtpParameters isn't that 
> hard.  It's not SDP munging :).
>
[RR] I think it should be simple too. I don't think what was included 
was rocket science but certainly it would be useful to go through each 
item. As for "why not just do this in a JS library". Personally, I 100% 
agree and would love to do exactly that, except currently the target 
level Capabilities we were originally planning lacks sufficient 
information to be able to write said JS abstraction. To be possible, 
we'd need to expand the target definition of what Capabilities should 
include to not be solely for other browsers engines' consumption but to 
also enable writing JS "createParameter" abstraction layers.