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

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

     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.

Gili

Received on Friday, 19 July 2013 15:43:56 UTC