Re: Schedule & spec organizations; giving priority to getUserMedia

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.

> But based on what you assess below about defining specific constraints
> later on, our views might not be that different. I think we need to have
> a definition of getUserMedia that lets us add constraints down the line;
> I think the current proposal is actually pretty close (if not exactly
> sufficient).
Definitely.
> It seems that we need to define getUserMedia in a way that the first
> parameter be used to refine what media streams are needed; as long as
> that first parameter can be extended to take on further refinements, we
> should be able to accommodate a more complex constraints API. Given how
> extensible dictionaries are, I think we're probably already on the safe
> side.
Good. "It's a dictionary, and you MUST ignore the members you don't 
know" seems like a necessary and sufficient API.
>
>> - PeerConnection depends only indirectly on getUserMedia - the common
>> denominator is MediaStream. But until we have a means of generating
>> mediastreams from other sources than getUserMedia, all practical
>> applications will be dependent on having getUserMedia.
> Just a clarification on "indirect dependency": what I specifically mean
> by dependency is not specification dependency, but implementation
> dependency; I can't imagine anyone shipping PeerConnection without
> getUserMedia, so I call that a dependency.
There are some cases where that would make sense (PeerConnection 
implemented for JS engines that run on headless machines), but for the 
main case (browser), I agree.

I was thinking spec dependency.
>> - The recorder interface is another example of a terminal point in the
>> graph: Nothing depends on it, so it can safely be delayed without
>> delaying other things
> Agreed; I had forgotten about that interface is my rough schema.
>
>> - Specific constraints definitions can be delayed by almost any amount
>> without much impact.
>>
>> So my dependency graph goes at least in part like this:
>>
>>             /--- Recorder interface
>>            /
>> MediaStream<------------------- GetUserMedia
>>                                   |
>> Constraints interface<---------+ PeerConnection (media)<---------------\
>>                                                                             \
>>                          Data API<-----------------------------------
>> PeerConnection (full)
>>
>>
>> Luckily, a number of things have drafts now, including the constraints
>> interface.
>> And we do have implementations of several of the proposed pieces.
> Again, I suggest we only focus on dependencies in the sense of
> implementations, not in the sense of spec dependencies.
I don't get the logic here. You started out your message pointing to a 
need to get specs out so that the W3C IPR rules would kick in; in that 
case, the critical point is the spec dependency.
The implementation dependency can be handled by each browser independently.

Received on Thursday, 22 March 2012 08:53:29 UTC