RE: Constraints as a separate interface

It's nullable in the current MediaCapture draft, so I kept it that way, but I guess it doesn't have to be.  Both the mandatory and the optional constraint sets can be empty in the general case.  (For example, if you're using MediaRecorder and use the platform defaults, constraints() will be empty, because you haven't applied any.) But there's not harm that I can see in returning an empty constraint structure.  

- Jim

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Monday, October 07, 2013 4:43 PM
To: Jim Barnett
Cc: public-media-capture@w3.org
Subject: Re: Constraints as a separate interface

Not that I have much time to look, but why is the return value from
contraints() nullable?  I'd have thought that it would always be possible to return an set of mandatory constraints and an empty list of optional constraint sets.

On 6 October 2013 15:09, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:
> Here’s an attempt to separate constraints out into a separate interface.
> The point is to allow other specs, such as MediaRecorder, to refer to 
> it and ensure that they are all using constraints consistently.  This 
> does _not_ change the semantics of constraints, it would just break 
> them out into a separate interface.  This interface would still be 
> defined in the MediaCapture spec, but in a separate section.  (There 
> would be editorial changes throughout the spec to refer to this 
> interface, but, again, the semantics of Tracks and Streams wouldn’t 
> change.)
>
>
>
> -          Jim

Received on Monday, 7 October 2013 20:50:35 UTC