Re: Constraints 2014

On 3/21/14 10:47 AM, Dominique Hazael-Massieux wrote:
> Thanks for your proposal.
>
> I find the syntax of that alternative approach vastly better (easier to
> read and write), and I like the simplified semantics. The WebIDL-based
> approach also feels like it will get us better consistency among
> implementations, and it also paves the way for clean extensibility.
> Finally, it is compatible with most of the code deployed today.

Thanks, glad you like it!

> What I'm more worried about:
> * the piece that infer media type from a specific constraint; I don't
> think that navigator.getUserMedia({aspectRatio: 4/3} clearly conveys
> you're requesting video

It is clear to the UA, but I think your concern is clarity to a reader. You can of course write:

   navigator.getUserMedia({video:true, aspectRatio: 4/3}

which, while redundant, is natural. I'm sure we can work this out (make explicit type a MUST if we feel justified).

> * more generally, it's guaranteed there will be lots of things to be
> worked out in detail given how different the proposal is — our existing
> constraints seem closer to to a stage where they could get implemented
> and deployed

Being an implementer of this, I find this mostly cosmetic actually - I don't like creating work for myself - I appreciate that the syntax is what most people see, so it appears like a big change to them, but semantically constraints are mostly unharmed. Even the optional order algorithm is in there (as prefer). Ideal is new but seems straight-forward.

The main fallout is the ability to repeat optional keys, but I haven't seen use-cases of that, except to target ideal values (covered by ideal), so that would be a win if there are none.

> 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 (but for the basic video, audio, peerIdentity), and move the
> constraints stuff into a separate spec where we can work out in details
> the algorithms, edge cases, etc.
>
> If the work on the new constraints prove to move fast enough, we could
> always consider merging it back in.
>
> Dom

.: Jan-Ivar :.

Received on Friday, 21 March 2014 15:58:53 UTC