Re: The mandatory constraint is a footgun

Jim,

     I thought your proposal was actually in line with what Martin is 
proposing. What he's saying is this:

 1. The developer enumerates the device capabilities and based on these
    asks for some set of constraints.
 2. The browser tries to honor the constraints, but if it fails to it
    fires "overconstrained".
 3. The reason overconstrained is very important is that capabilities
    change over time. Initially I could deliver 1080p but suddenly my
    network pipe is congested or my CPU is overtaxed (by concurrent
    applications) and so the WebRTC application is going to need to
    adjust (e.g. by reducing the screen resolution for now, and
    increasing it back up at a later time).

Gili

On 13/11/2013 1:00 PM, Jim Barnett wrote:
> Now I'm really confused.  What do you mean by 'constraints being initial settings"?  In the current draft, they can be applied at any point.  The initial setting (i.e. before the app applies any constraints) is chosen by the UA, and can be anything it wants (within the range of the capabilities it supports.)
>
> - Jim
>
> -----Original Message-----
> From: Martin Thomson [mailto:martin.thomson@gmail.com]
> Sent: Wednesday, November 13, 2013 12:57 PM
> To: Jan-Ivar Bruaroey
> Cc: public-media-capture@w3.org
> Subject: Re: The mandatory constraint is a footgun
>
> On 11 November 2013 22:04, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>> I've implemented a strict interpretation of the spec's mandatory
>> constraint that treats unknown keys as unsupported, I've tried it, and
>> I think it is wrong.
> I tend to agree.
>
> We've had this discussion several times. Usually it's when someone has sat down and carefully thought out the real impact that this has on users and applications.
>
> I'm going to go out on a limb and make a bit of a radical suggestion.
> The following functions are sufficient:
>
>   * Enumerate devices with quasi-stable identifiers.
>   * Select a specific device.
>   * Ask the browser to select a device.
>   * Apply settings to MediaStreamTrack instances.
>   * Get the set of supported settings, and their acceptable ranges.
>   * The overconstrained event (i.e., the settings couldn't be applied event).
>
> I can't think of a good use case that isn't supported by that set of features.  If we think of constraints as initial settings, I think that we could make them a whole lot simpler.
>
> Though I don't like being contrary when your logic is so rational, I have concluded that it's the mandatory set that we keep, and the optional parts that are removed.  Though I solidly agree about the part where you point out that unsupported/unknown attributes have to be ignored.
>