Re: Schedule & spec organizations; giving priority to getUserMedia

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.

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).

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.


> - 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.

> - 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.

Dom

Received on Thursday, 22 March 2012 08:03:04 UTC