Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface

On 19/07/2013 11:57 AM, tim panton wrote:
> Hi Tim,
>
>     I'm pretty sure now I used the wrong terminology. When I say imperative API versus passing in a map I simply mean that that we break the functionality down into individual API methods instead of passing in a big map. Nothing about this approach forces the API to be low-level. It just means that instead of setting a bunch of properties at once, you get/set them in smaller chunks. Interacting with API methods allows us to fail-fast, throw context-specific exceptions and introduce instruction ordering in a way that is awkward for maps.
>
>     And to get back to your point, the API should enable users to "Tell, Don't Ask": http://programmers.stackexchange.com/a/157527/42177
> Which requires that the api should be around generic concepts, not exposing codec specific controls/modes, otherwise the
> first thing you have to do is query the codec "do you support quality setting?" which rapidly degenerates into
> "are you Opus v 1.1 ?"

     That's fine (build the API around generic concepts). Just don't 
expose it as a big map (a map is not an API) and don't expose 
implementation-specific functionality as is currently the case with 
inter-op constraints. Inter-op belongs in the signaling layer, not in 
the API layer.

> And there in lies the problem - say I set that I want high framerate, then later that I want low bandwidth, what is the codec supposed to assume about the relationship between these two statements ? Do they both apply? Does one override the other ? They (may depending on the codec) both change the codec mode in opposite directions.
> If you set them both at the same time in an ordered map then the intention is clearer.

     First of all, nothing prevents an API method from taking multiple 
parameters at once. But that being said, there are different ways of 
handling this:

 1. Throw an exception if a conflict is detected.
 2. Assign priorities to each constraint (I believe this is already
    being discussed).
 3. Replace mandatory/optional constraints with "fences" and invoke a
    user callback when these fences are crossed. For example, I
    configure a minimum resolution of 1080p and minimum bandwidth of
    3Mbit. At some point, the available bandwidth drops below 3Mbit. My
    callback gets invoked (notifying me this has happened) so I set new
    constraints: minimum resolution 720p, bandwidth between 1Mbit,
    3.5Mbit. Some time later, the bandwidth increases past 3.5Mbit. I
    respond by restoring the original constraints of 1080p and minimum
    bandwidth 3Mbit. And so on. This simplifies the constraints model a
    lot and also makes it a lot more flexible.

Gili