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

On 19 Jul 2013, at 16:43, cowwoc <cowwoc@bbs.darktech.org> wrote:

> On 19/07/2013 6:53 AM, tim panton wrote:
>> On 19 Jul 2013, at 03:03, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>>    Short answer: yes.
>>> 
>>>    Long answer: if we're going to go with an Object API I recommend going a lot further than the current Constraint API. Populating a key-value map is not an API in my book; it's also the reason I think SDP is a poor match for end-users. We can (and should) do a lot better by exposing an imperative API.
>>> 
>> The original constraints idea was for the web programmer to express in _their_ terms what the application they were writing needs. So they state that LowlatencyAudio (for a choir) is required or HighFrameRate video (for a motor racing broadcast) and the browser does it's best to translate that into whatever is needed in the (opaque to the Javascript user) SDP.
>> 
>> The problem with an imperative API is that you _very_ soon end up exposing the codec names or worse
>>  Quality/Complexity/etc settings of the codecs - who's meanings are even _less_ clear than SDP :-) . The only way to avoid that is to couch the requirements in more generic terms, which brings you to the constraints style above.
> 
> 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 ?" 

> 
>    This implicitly addresses a discussion brought up elsewhere on this list that we should move a big up-front Offer/Answer to a model where a small number of constraints change over time.
> 

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.


Tim.
> Gili
>

Received on Friday, 19 July 2013 15:57:37 UTC