Re: New Editor's draft v20131225

Hi Dan, thanks for doing the update.

Some quick comments.

On 12/25/13 10:31 PM, Dan Burnett wrote:
> Hi
>
> A new version of the editor's draft is available.
>
> Dated version: http://dev.w3.org/2011/webrtc/editor/archives/20131225/getusermedia.html
> Living document: http://dev.w3.org/2011/webrtc/editor/getusermedia.html
>
> Changes include:
> * ACTION-25: Switch mediastream.inactive to mediastream.active.
> * ACTION-26: Rewrite stop to only detach the track's source.
> * Bug 22338: Arbitrary changing of tracks.
> * Bug 23125: Use double rather than float.

Tiny nit: grepping for 'float' turns up 
http://dev.w3.org/2011/webrtc/editor/getusermedia.html#capabilities-constraints-and-settings 
which still mentions float as an etc. in the prose. Also, 'int' is not 
valid in webidl ('long' would be).

> * Bug 22712: VideoFacingMode enum needs an illustration.

Can you help me understand what left and right are for? I was surprised 
to see them still pointing essentially toward the user rather than in 
opposing directions, but then I never understood their purpose. 3D? If 
so, why are they not pointing toward the environment? (the old HTC Evo 
3D phone had its stereo cameras pointing toward the environment FWIW - 
not saying they all do).

> * Moved constraints into a separate Constrainable interface.

Are you looking for feedback of the text or has it just moved? I'll post 
my comments for this section in any case:

I would strike the word "partial" from the text "[ The Constrainable 
interface] is broken out as a separate partial interface so that it can 
be used in other specifications. ", since this is not a partial 
interface (a partial interface being a way of adding to an existing 
interface, like this: interface a { int b; }; partial interface a { int 
c; } for a result identical to interface a { int b; int c; }

But a larger problem I see with this sentence and the Constrainable 
interface itself, is the notion that other specifications can implement 
this webidl interface as it stands. I don't think they can, not without 
changing what the concepts "Capabilities", "Constraints" and "Settings" 
point to, unless they're going to play in the same pool of known 
constraints. I have to ask why we're attempting this abstraction, 
because the benefits are not clear to me as an implementer or a user.

Can you give me an example of how another spec might use it, and how 
that would work exactly?

The Constrainable interface itself appears unchanged, and has problems 
I've mentioned before. In short:


[NoInterfaceObject]
interface Constrainable {
     readonly    attribute Capabilities capabilities();
     readonly    attribute Constraints  constraints;
     readonly    attribute Settings     settings;
                 attribute EventHandler onoverconstrained;
     void applyConstraints (Constraints constraints, VoidFunction successCallback, ConstraintErrorCallback errorCallback);
};

at least needs to be:

[NoInterfaceObject]
interface Constrainable {
     Capabilities getCapabilities();
     Constraints  getConstraints();
     Settings     getSettings();
     attribute EventHandler onoverconstrained;
     void applyConstraints (Constraints constraints, VoidFunction successCallback, ConstraintErrorCallback errorCallback);
};


in order to be valid. The reason is dictionaries cannot be attributes, 
and the prose still has Capabilities and Settings as dictionaries, which 
I believe they'll continue to be.

> * Created a separate section on error handling.

About:

[NoInterfaceObject]
interfaceMediaError  {
     readonly    attribute DOMString  name;
     readonly    attribute DOMString? message;
     readonly    attribute DOMString? constraintName;
};


Did we really decide to do this? I thought we were going with plain 
DOMError. How much should we warp the universe to make mandatory usable?

Lets not add this. Firefox already gives you the name of the constraint 
that failed in the message, which is super-trivial to find in JS (and if 
not found, big deal. The end user gets a less than stellar error 
message, right? The call failed and it was mandatory, so there can't be 
another reason).

> Please review and provide feedback.
>
> Dan Burnett (for the editors)

.: Jan-Ivar :.