Re: WebIDL ConstrainablePattern discussion

On 4/15/15 2:43 PM, Jason Ausborn wrote:
> After consolidating WebIDL from the working draft, I processed 
> it with the W3 WebIDL checker. The checker had errors regarding the 
> ConstrainablePattern interface for undefined Capabilities and Settings 
> types.
>
> Current:
>
> [NoInterfaceObject]
> interface ConstrainablePattern {
> *Capabilities*  getCapabilities ();
>     Constraints   getConstraints ();
> *Settings*      getSettings ();
>     Promise<void> applyConstraints (Constraints constraints);
>                 attribute EventHandler onoverconstrained;
> };
>
>
> Recommended:
>
> [NoInterfaceObject]
> interface ConstrainablePattern {
> *object*  getCapabilities ();
>     Constraints   getConstraints ();
> *object*     getSettings ();
>     Promise<void> applyConstraints (Constraints constraints);
>                 attribute EventHandler onoverconstrained;
> };
>
>
> The above changes will pass with the WebIDL Checker. Note, changing 
> *object *to *any *will work also (as well as other defined types).

Changing to object would be misleading I think.

Disclaimer: As far as I'm concerned the whole ConstrainablePattern can 
be scrapped and its prose collapsed into corresponding actual interfaces 
in MediaStreamTrack.

Those concerns notwithstanding, the above errors seem solvable the same 
way the sibling 'Constraints' dictionary is pacified, with empty 
dictionary definitions in 11.5. [1]

> I was confused after reading *11.1 Interface Definition *in regards to 
> "*limitations of the interface definition language* used in this 
> specification".

The ConstrainablePattern is not an actual interface in any 
implementation, rather it is an attempt to elevate parts of the 
MediaStreamTrack API into a reusable pattern, presumably for 
documentation reasons and hopes of future re-reference (I wont say reuse 
since it's not actually used). The working group is trying to express 
this using WebIDL by defining an interface that isn't meant to be 
implemented directly and whose names are similar to APIs that are meant 
to be implemented. E.g.

Constraints, see MediaTrackConstraints
Capabilities, see MediaTrackCapabilities
Settings, see MediaTrackSettings
ConstrainablePattern.*, see MediaStreamTrack.*

As I'm sure you know, WebIDL mints concrete interfaces based on explicit 
definitions only, not from reusable templates or patterns, and cannot 
express this. I believe these are the "limitations" referred to.

> WebIDL states that the *[NoInterfaceObject]* extended attribute 
> should be solely used on *supplemental *interfaces. IMO, I recommend 
> rephrasing the *11.1 Interface Definition *description. Consider 
> rewording *limitations of the interface definition language*, and 
> consider adding *supplemental interface* somewhere in the description.

This seems like the elephant on the baseball field has a non-regulation 
cap, type of problem.

It is probably a supplemental interface in spirit, at least more than it 
is the opposite, since we'd like to write:

     MediaStreamTrack implements ConstrainablePattern;

if it weren't incorrect and misleading to do so. If it were supported, 
we would have had to write something like:

     MediaStreamTrack implements 
ConstrainablePattern<MediaTrackConstraints, MediaTrackCapabilities, 
MediaTrackSettings>;

i.e. an instantiation of a template pattern, but that's made up and not 
WebIDL.

Hope that clears things up.

.: Jan-Ivar :.

[1] http://w3c.github.io/mediacapture-main/getusermedia.html#constraints