Re: About the Mandatory constraints

On 2014-02-05 21:26, Jan-Ivar Bruaroey wrote:
On 2/5/14 1:34 PM, Stefan Håkansson LK wrote:

There has been some discussion about mandatory constraints again lately
in the context of constraints for the MediaStream Recorder.

I think the use of constraints for the Recorder is something we have not
really discussed yet, but I think (though I may be wrong) some mails
tended to question the need for mandatory constraints also for gUM.

You are not wrong:

On 2/5/14 1:17 PM, Robert O'Callahan wrote:
On Thu, Feb 6, 2014 at 6:29 AM, Cullen Jennings <fluffy@iii.ca<mailto:fluffy@iii.ca>> wrote:
Is this a proposal for GUM for Recording or both?

Both. Paragraphs 1-4 apply to both.

Paragraphs 3 and 4 being:
3) Eliminate getConstraints(). The application can determine which constraints were satisfied by inspecting object state using #2.
4) Eliminate mandatory constraints for the same reason.


On 2/5/14 1:34 PM, Stefan Håkansson LK wrote:

Just to be clear: I think we have debated the mandatory constraints for
gUM several times, and we always come back to the same conclusion:
people want them. One use is when the app developer wants to avoid
disturbing the user, or even indicate e.g. that video communication is
possible, if the equipment does not fulfill the requirements the app
developer has.

Some people think it would be more natural to just get access to the
camera (and in the process launch a prompt), then check what it can
fulfill the needs, and if not tell the user that "sorry, your camera is
not good enough". But those developers can skip using mandatory constraints.

Well described. Thank you for succinctly nailing the lone benefit of mandatory constraints: to avoid a permission prompt in a failure case.

BTW, gUM has a permission prompt, MediaRecorder does not.


Let's not debate if we need mandatory constraints or not for gUM again.
I think it would be much more fruitful if we could have the details in
Constrainable reviewed for use with gUM and MediaStreamTracks. I would
be really happy we could nail a design that fulfills the needs we have
there.

I think we would be done discussing constraints if not for people trying to elevate Constrainable to a general interface and foisting it on other APIs. That's a higher bar that opens the door for further scrutiny.

It does. But I insist: having the details reviewed (for gUM use) would be really helpful. If we can get to the point where we are "done discussing constraints" for gUM we have a design for the main use case. Implementers could go on and implement, developers could start using, and we could separately discuss how and if we make it reusable for other specs (I may be naïve, but my hope would be that it could be quite transparent to implementers/users of gUM).


I would be happy to scrutinize other uses of the interface if there were any.

Since there aren't, are we not supposed to talk about that the elephant being sold has five legs, or that how it got five legs was controversial?

Sure. But I don't want that discussion take the focus completely away from the details of gUM use.


.: Jan-Ivar :.