Re: Constraints 2014

On 03/26/2014 03:24 PM, Jan-Ivar Bruaroey wrote:
> On 3/26/14 4:31 AM, Harald Alvestrand wrote:
>> On 03/26/2014 02:18 AM, Jan-Ivar Bruaroey wrote:
>>> Sure, that is certainly doable, if people prefer, or we could
>>> perhaps do videoSourceId and audioSourceId? Things don't seem to
>>> overlap much otherwise.
>>
>> If they don't overlap, to me that's an argument for keeping each in
>> its own bag.
>> If they overlap, to me that's an argument for keeping each in its own
>> bag; separation of concerns.
>
> First of all, I'm delighted we're discussing what I consider mostly
> naming, e.g. video::sourceId vs. videoSourceId, frameRate vs. maybe
> video::rate - I don't hold a strong opinion, but I'm curious.
>
>> It seems hard to find an argument that would convince me that mixing
>> audio and video constraints into one bag is a good idea :-)
>>
>> (this is about how we pass the bag/bags to gUM. That's separate from
>> the question of whether having different type definitions for the two
>> is a great idea or not.)
>
> Let me play devil's advocate then: A camera and a mic - light and
> sound - are so similar - rather than complements - that their
> properties don't deserve separation by TYPE, and we must use bags to
> keep their otherwise ambiguous settings apart?

I have my own opinions about the advisability of separating similar
things by type.

One of my co-workers once commented on data definition languages that
they "bind before compile time". He was a fan of late binding.


>
> If we had, say, transport properties - like bandwidth - then I would
> see why. Bits are bits. But we don't. That's over in PeerConnection.
>
> I actually had things broken down in an earlier draft (below), but typed.
>
> .: Jan-Ivar :.
>
> (EARLIER DRAFT USING AUDIO & VIDEO GROUPS)
>
> dictionary MediaStreamOptions {
>     (boolean or VideoTrackConstraints) video = false;
>     (boolean or AudioTrackConstraints) audio = false;
>     DOMString peerIdentity;
> };
>
> dictionary Constraints {
>     sequence<DOMString> require; // names of required constraints, if any
>     sequence<DOMString> prefer;  // names of preferred constraints, if any
> };
>
> dictionary VideoTrackConstraints : Constraints {
>     ConstrainLong width;
>     ConstrainLong height;
>     ConstrainDouble aspectRatio;
>     ConstrainDouble frameRate;
>     ConstrainVideoFacingMode facingMode;
>     // Dictionary may be extended through gUM-specific IANA registry.
> };
>
> dictionary AudioTrackConstraints : Constraints {
>     ConstrainDouble volume;
>     ConstrainLong sampleRate;
>     ConstrainLong sampleSize;
>     boolean echoCancelation;
>     // Dictionary may be extended through gUM-specific IANA registry.
> };
>
> interface VideoStreamTrack : MediaStreamTrack {
>     VideoTrackConstraints getInherentCapabilities();
>     VideoTrackConstraints snapshotCurrentSettings();
>     void applyConstraints(VideoTrackConstraints settings,
>                           VoidFunction successCallback,
>                           ConstraintErrorCallback errorCallback);
> };
>
> interface AudioStreamTrack : MediaStreamTrack {
>     AudioTrackConstraints getInherentCapabilities();
>     AudioTrackConstraints snapshotCurrentSettings();
>     void applyConstraints(AudioTrackConstraints settings,
>                           VoidFunction successCallback,
>                           ConstraintErrorCallback errorCallback);
> };

... and if WebIDL had offered the option of passing / returning an
AudioTrackConstraints structure in where a Constraints is declared in
the WebIDL, we could have a common interface instead of declaring the
same set of functions twice ....

Part of the naming issue here is caused by the fact that WebIDL tries to
be a strongly typed language, without the functionality that other
strongly typed languages have for doing this sort of thing, while
interfacing to a very weakly typed language (Javascript).

-- 
Surveillance is pervasive. Go Dark.