Re: Constraints 2014

On mar., 2014-03-25 at 09:43 +0100, Harald Alvestrand wrote:
> How would this work in practice?
> 
> The places where the constraints touch the spec at the moment are:
> 
> - gUM's first argument
> - the applyConstraints, settings and capabilities call
> 
> Would we then go with a dummy first argument to gUM that took only the 
> boolean variants, and specify in a footnote that we would expect the 
> booleans to be augumented with an alternative that is some more 
> extensive structure at some later stage (the exact form of which is not 
> yet specified)?

Right; more specifically, we would have a dictionary as the first
argument of gum with only the boolean members audio, video and
peerIdentity; the constraints spec would define a partial dictionary
that would extend that dictionary with the actual constraints.

Likewise, I would expect the Capabilities / Settings / Constraints
methods to move to that other spec.

> My fear is that since the use cases of the applications that people 
> develop can't be satisfied without some form of constraint on gUM, this 
> would remain application dependent (and thus non-portable) until we come 
> to agreement.

That remains true no matter where we define it (in the same spec or
separately).

On a broader note, we've heard from the WebRTC list that there are
already quite a few products out there based on WebRTC; this implies
that there are a number of real world applications that have managed to
live so far without more advanced control on media streams (or at least
without more advanced *interoperable* control on media streams). 

To be absolutely clear, I very much support getting constraints done and
finished as soon as we can; but I would rather not having them delay or
create uncertainties around the more mature part of our work.

Dom

Received on Tuesday, 25 March 2014 13:50:48 UTC