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

On Fri, May 9, 2014 at 3:28 PM, Robin Raymond <robin@hookflash.com> wrote:

>
> [RR] See inline
>
>   Peter Thatcher <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.
>

Advanced use cases can build RtpParameters themselves.  Or, they can do a
mix: ​call createParameters to fill in the basic stuff, and then add the
layering/simulcast stuff you need.  Really, it doesn't seem that hard to
me.  I don't think we need to make createParameters/filterParameters be
everything to everybody.  Just do the basics and then let the JS do
advanced stuff.



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

​I may be wearing you out having to hear this, but if the RtpCapabilities
are lacking important things, let's add them.  If you don't like
createParameters/filterParameters for you use cases, then just ignore them.
 Don't use them.  But people with simple use cases will appreciate them.
 There are lots of use cases that don't involve simulcast and layering.
 The 1.0 spec doesn't even include them at all!