Re: Spec question: Using settings dictionaries instead of MediaConstraints

On 06/20/2012 10:03 PM, Justin Uberti wrote:
>
>
> On Wed, Jun 20, 2012 at 11:11 AM, Harald Alvestrand 
> <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>
>     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.
>
>
> That's pretty much what I had in mind, I didn't realize that 
> constraints already had ordering for optional items.
>
> The question becomes how do we best indicate which constraints can be 
> passed to the various API calls - I was thinking we can have different 
> types of XXXXConstraints for different API calls, and we can indicate 
> what values are valid for each type of XXXXConstraints where we 
> declare the type.
>
> Open to other ideas too though.
Have a requirement in the registry for what effect they're supposed to 
have at each API? (no documentation = not allowed)?