Re: Proposal: Constraints as dictionaries

On 11/20/13 8:27 PM, Martin Thomson wrote:
> I think that this is just an oversight, but you haven't allowed for
> the distinction between different source types very well in A.  And,
> given that different source types are going to be very different in
> terms of what constraints are supported, you either need to fix
> getSupportedConstraints() so that it returns different values for
> different types of sources, or maybe you can avoid it altogether and
> just have someone construct a track and poke around in the result from
> capabilities().

It is my understanding that video and audio constraints share the same namespace. From http://dev.w3.org/2011/webrtc/editor/getusermedia.html#methods-3 :

  "For each constraint key-value pair in the "optional" sequence of the constraints that are for the current media type, in order,"

(btw, that is section 9.1.1. Should I be alarmed?)

So this shouldn't be a problem.

My takeaway from your point is that this requires browsers to implement a constraint for all media types it applies to, at the same time. I'm OK with that.

> In terms of the different range values, I think that a single
> NumericPropertyRange is going to be sufficient.  These generalize
> fairly well, even if the full, possible, specified range isn't
> exercised.  For instance, 0.3 to 10.1 is for all intents equivalent to
> 1 to 10 in ordinal values.  If the application wants to specify 0.3 to
> 0.4 on a property that only supports ordinal values, that's
> overconstrained.  That's how JavaScript works anyway.

By the same argument we should use double everywhere. Are you saying we should use double everywhere?

I mean, you're right, but unless you are saying we should use double everywhere, I think right here this is clever for no gain. There is no webidl budget for dictionaries, and no cost to being specific here, so I think we should be specific.

WebIDL distinguishes between long, float and double, and webidl compilers generate bindings for multiple languages. Our implementation happens to be both in JS and (underlyingly) in c++. In any implementation (especially c++), implementers expect the limits in the same type as the value they apply to, and so does the caller, I would argue.

If you're taking on webidl types, can we do away with the abominable unsigned keyword first? I will join you in that. :-)

> I like C a lot, especially since it effectively changes the behaviour
> in response to a naive choice [{ stuff I want }] to the intuitive
> behaviour, i.e., mandatory.

Great!

.: Jan-Ivar :.