Re: Schedule & spec organizations; giving priority to getUserMedia

On 03/22/2012 09:52 AM, Harald Alvestrand wrote:
> On 03/22/2012 09:02 AM, Dominique Hazael-Massieux wrote:
>> Hi Harald,
>>
>> Le mercredi 21 mars 2012 à 20:22 +0100, Harald Alvestrand a écrit :
>>> I disagree with some of your prioritizations:
>>>
>>> - for the final getUserMedia API, the constraints API must be specified,
>>> because constraints are part of the getUserMedia API, and cannot be
>>> added afterwards.
>> I challenge that view; I'm fairly sure that we'll see implementations of
>> getUserMedia on the market that don't integrate the constraints APIs (we
>> already do, in fact), in particular because the constraints API won't be
>> ready in time for the schedule that implementers have in mind. But
>> that's a guess —  I think we should ask implementers and align with
>> their intent. We should probably ask that on the Media Capture TF
>> mailing list.
> What we see today is people stuffing "video:true, audio:true" into the
> place where the current discussions indicate that the constraints API is
> going to be (unless we change away from the current shape of getUserMedia).
>
> Those implementations are going to be broken if that space in the
> arguments list gets used for a constraints API.
>
> The rest of stuff that has to do with constraints can wait - but the
> particular syntax that is going into that place on the argument list has
> to be compatible with what we end up with as a constraints API before we
> declare that specification stable.
>
> but yes, the argument list for getUserMedia is a discussion that the
> media capture TF needs to have.

I've posted a proposal on how to introduce the constraints to 
getUserMedia() on the public-media-capture list.

http://lists.w3.org/Archives/Public/public-media-capture/2012Mar/0073.html

/Adam

Received on Thursday, 22 March 2012 12:27:04 UTC