Re: Spec question: Using settings dictionaries instead of MediaConstraints

On 06/20/2012 04:56 PM, Justin Uberti wrote:
>
>
> On Wed, Jun 20, 2012 at 9:21 AM, Harald Alvestrand 
> <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>
>     On 06/19/2012 03:45 PM, Justin Uberti wrote:
>>
>>
>>     On Tue, Jun 19, 2012 at 8:57 AM, Stefan Hakansson LK
>>     <stefan.lk.hakansson@ericsson.com
>>     <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>>
>>         On 06/19/2012 08:30 AM, Randell Jesup wrote:
>>
>>             On 6/18/2012 3:22 PM, Justin Uberti wrote:
>>
>>
>>
>>                 On Mon, Jun 18, 2012 at 2:57 PM, Cullen Jennings (fluffy)
>>                 <fluffy@cisco.com
>>                 <mailto:fluffy@cisco.com><mailto:fluffy@cisco.com
>>                 <mailto:fluffy@cisco.com>>>  wrote:
>>
>>
>>                     This seems like good proposal, one comment on a
>>                 small detail.
>>
>>                     On Jun 15, 2012, at 1:28 PM, Justin Uberti wrote:
>>
>>                 >  SessionDescriptionOptions.IncludeAudio =
>>                 true/false // forces
>>                     m=audio line to be included
>>                 >  SessionDescriptionOptions.IncludeVideo =
>>                 true/false // forces
>>                     m=video line to be included
>>                 >
>>                  SessionDescriptionOptions.UseVoiceActivityDetection
>>                 = true/false
>>                     // includes CN codecs if true
>>
>>                     I think these three should be constraints, not
>>                 settings because a
>>                     given browser may not support any of them.
>>
>>
>>                 Practically speaking, what does that mean for
>>                 applications?
>>
>>
>>             I can conceive of a browser implementing audio but not
>>             video.  And a
>>             gateway or other stand-alone WebRTC box/functionality
>>             might include JS
>>             and these JS apis for ease of programming (and might be
>>             audio-only).
>>             (I'd try to avoid it in production, probably, but even
>>             that might not be
>>             needed with modern JS JIT speed so long as it didn't have
>>             to tear down
>>             and restart all the time.)
>>
>>             CN codecs: I dislike them anyways.  :-)  An
>>             implementation definitely
>>             could avoid including those.
>>
>>
>>         Many codecs have built in CN modes. I guess for those it is
>>         more a question of being able to switch off the VAD.
>>
>>
>>     I agree with the scenarios mentioned - my question was mostly
>>     about what does having these settings be "constraints" vs
>>     "settings" mean for users of the API. Is it simply that the call
>>     must fail if the request can't be satisfied?
>
>     If they are constraints, it's the caller's choice whether or not
>     the call should fail if the constraint can't be satisfied (listing
>     them in "mandatory" vs "optional" sections).
>
>     If they are settings, it's the specification's choice whether or
>     not the call should fail if the constraint can't be satisfied; it
>     has to be always handled the same.
>
>     At least that's how I read it.
>
>
> That makes sense. So perhaps we add .mandatory and .optional to make 
> these dictionaries into SessionDescriptionConstraints/IceConstraints, e.g.
>
> constraints = {};
> constraints.mandatory.getCapabilities = true;
> constraints.optional.includeAudio = true;
> constraints.optional.includeVideo = true;
> pc.createOffer(successCb, failCb, constraints);
>
> and we end up with MediaConstraints, SessionDescriptionConstraints, 
> and IceConstraints that all act the same way.
Now the only difference between these constraints (?) and the 
constraints defined in the getUserMedia draft is the initializer syntax 
and the fact that we can't say that some optional constraints are more 
important than others.

If we're that close, I'd recommend going with the getUserMedia-specified 
syntax.

Let's just do one.