Re: getUserMedia WebIDL feedback

On Jun 7, 2012, at 11:36 AM, Dominique Hazael-Massieux wrote:

> Le jeudi 07 juin 2012 à 11:26 -0400, Dan Burnett a écrit :
>>> * rather than minting our own error object (NavigatorUserMediaError), it
>>> is recommended to use instead DOMError; NotSupportedError is already a
>>> well-defined DOMError type [2]; MANDATORY_UNSATIFIED_ERR isn't, but I'm
>>> not sure we need a separate code; PERMISSION_DENIED might be replaced
>>> with SecurityError (but that's probably worth checking with
>>> www-dom@w3.org)
>> 
>> I am happy to use more appropriate error messages where they exist.
>> It is *extremely* important to the constraint approach that an author
>> can know when a mandatory constraint could not be satisfied.
> 
> Could you elaborate on that? 

One of the primary goals of the constraints approach, from the beginning, was to allow an author the ability to indicate "must satisfy" constraints that either must be satisfied or an error is returned.  For example, if my application only has a 200x200 pixel space for an image, It is useless to me to be provided something larger.
If getUserMedia() fails to return a stream, as an app author I would want to know whether it was because of a permissions failure or because of a constraint that could not be satisfied.

> 
>>> * I'm not sure we need to report an error set of constraints that cannot
>>> be satisfied (vs only when none of the possible options can be
>>> satisfied)
>> 
>> For mandatory, we need to at least indicate that the mandatory
>> constraints could not all be simultaneously satisfied.  I think it
>> would be helpful to also receive, with that error message, at least
>> one of the mandatory constraints that could not be satisfied.
> 
> If that is the case, then DOMError might not be the best approach; but
> what's the use case behind reporting which constraint couldn't be
> satisfied? (that leaks information, hence my asking)

It leaks no more information than merely indicating that a mandatory constraint has failed.  It is possible to try each constraint individually or multiple times if the goal is to collect capability information.
The reason to report the failed constraint is so the application code can adjust the user interface accordingly.  As has been pointed out several times on this and the WebRTC lists, true capabilities can change between when capabilities information is obtained via getCapabilities() and when the call to getUserMedia() actually happens.

> 
>>> 
>>> * I think the type for MediaStreamConstraints member should be (boolean
>>> or MediaTrackConstraints) [rather than DOMString, and instead of
>>> including the dictionary keyword in the type]; the default values should
>>> be set to false;
>> 
>> Actually, I had heard someone (I think it was Anant) say that use of
>> enums and booleans was deprecated in favor of DOMString.  If that's
>> not true, and we should use booleans, then I'm happy to do so.
>> Anant?
> 
> I'm quite sure that enums and boolean are not deprecated :) What has
> been deprecated is pseudo-enums using integer constants (in favor of
> string based enums).

Ah, okay.  Then I am happy to correct as you suggest.

> 
> 
>>> * the type for the 1st member of MediaTrackConstraints also includes a
>>> buggy "dictionary" keyword; instead of a sequence<>, the second member
>>> should use an array
>> 
>> You are probably right.  I will check this.  The WebIDL spec is not very clear on some of this.
> 
> Feel free to check, but I'm quite confident on this. FWIW, I wrote and
> maintain the WebIDL checker, and maintain the underlying widlproc
> parser, so I think I'm reasonably well aware of WebIDL and at least its
> syntactic intricacies :)

I bow to you, oh god of WebIDL (and will fix the syntax as you suggest).

> 
> Dom
> 
> 
> 
>

Received on Sunday, 10 June 2012 15:10:45 UTC