Re: Schedule & spec organizations; giving priority to getUserMedia

Le jeudi 22 mars 2012 à 09:52 +0100, Harald Alvestrand a écrit :
> 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.
> 
> Good. "It's a dictionary, and you MUST ignore the members you don't 
> know" seems like a necessary and sufficient API.

+1

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

Our specs can only get RF protection once they are implemented by at
least two browsers; so to give RF protection to our specs as fast as
possible, we need to focus on what is being implemented by at least two
browsers. Therefore, we need to focus on what browsers will consider as
dependency (i.e. they won't ship one without the other).

Does that clarify what I mean?

Dom

> 
>

Received on Thursday, 22 March 2012 09:10:12 UTC