Re: Constraints 2014

On 03/25/2014 09:15 AM, Dominique Hazael-Massieux wrote:
> Hi Cullen,
>
> On sam., 2014-03-22 at 12:29 -0600, Cullen Jennings wrote:
>> On Mar 21, 2014, at 8:47 AM, Dominique Hazael-Massieux <dom@w3.org> wrote:
>>
>>> I think I might be convinced to switch to this new approach, if we work
>>> it out separately from the main getUserMedia spec; in other words, we
>>> would freeze (e.g. move to LC) the current getUserMedia without any
>>> constraints
>> GUM does not meet it uses cases without this
> GUM does not meet all its use cases without this, agreed; and I too
> really see the need for constraints in my development work. But my
> proposal is not about making GUM not meeting all its use cases, but
> scheduling our work to match the state of implementations.
>
> Right now, it seems to me there is still lots of uncertainties around
> constraints; even if we were to stick to the current design, there seems
> to be still some significant amount of work before we can declare them
> bug free (as J-I's recent reports have shown).
>
> It feels like the rest of GUM is a lot more stable, and a lot more
> widely implemented; I think we would do the world a better service by
> freezing and testing that stable and implemented part, than by leaving
> the whole spec as tentatively changeable (which is what we communicate
> by sticking to simple Working Drafts).
>
> Splitting out a part of the spec is not saying that part won't be done;
> it's simply the recognition that that part requires a different
> schedule. And if we manage in fact to make faster progress on
> constraints, we can always remerge them in the main spec (and I'm
> willing to do the grunt work of splitting / merging if that's an
> obstacle).

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

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.

Received on Tuesday, 25 March 2014 08:43:52 UTC