W3C home > Mailing lists > Public > public-media-capture@w3.org > June 2012

Re: getUserMedia WebIDL feedback

From: Dan Burnett <dburnett@voxeo.com>
Date: Thu, 7 Jun 2012 11:26:34 -0400
Cc: public-media-capture@w3.org
Message-Id: <88C838C1-E5C8-4E1D-BBD1-67D53B479B19@voxeo.com>
To: Dominique Hazael-Massieux <dom@w3.org>

On Jun 4, 2012, at 10:01 AM, Dominique Hazael-Massieux wrote:

> Hi,
> 
> A few comments on the latest editors draft for getUserMedia [1], in
> particular with regard to its WebIDL usage, and also based on notes I
> took while writing test cases.
> 
> I don't think any of these should prevent us from moving forward with a
> FPWD, FWIW.
> 
> Also, I'm happy to bring some of the changes myself to the github
> version if that's preferred.
> 
> * MediaStream has a onended settable attribute; shouldn't it be
> inheriting from EventTarget so that one could use addEventListener (and
> thus record several listeners for the event)
> 
> * likewise for MediaStreamTrack and onmute/onunmute/onended, and
> MediaStreamTrackList with onaddtrack, onremovetrack
> 
> * I'm not clear why the "onended" events aren't triggered when
> MediaStream::stop() is invoked; an explaining note would probably be
> useful
> 
> * there are strong requirements on the label attribute for MediaStream,
> but nothing in getUserMedia relies on these requirements  they're
> intended for PeerConnection use cases as far as I can tell; maybe a note
> to that effect would be useful (the alternative would be to move the
> requirements to the WebRTC draft, but that seems a bit heavy handed for
> something that simple)
> 
> * readyState on MediaStreamTrack uses integer constants, instead of the
> now recommended string ones
> 
> * it's a tad confusing that MediaStream has a boolean for ended, when
> MediaStreamTrack has a ternary value with readyState; not sure if it's
> worth harmonizing though
> 
> * the URL section should link to http://www.w3.org/TR/url/
> 
> * I'm not sure what's the point of having the success callback for
> getUserMedia to be nullable since the only effects is to abort the call

Good point.  This should be fixed.

> 
> * rather than minting our own error object (NavigatorUserMediaError), it
> is recommended to use instead DOMError; NotSupportedError is already a
> well-defined DOMError type [2]; MANDATORY_UNSATIFIED_ERR isn't, but I'm
> not sure we need a separate code; PERMISSION_DENIED might be replaced
> with SecurityError (but that's probably worth checking with
> www-dom@w3.org)

I am happy to use more appropriate error messages where they exist.  It is *extremely* important to the constraint approach that an author can know when a mandatory constraint could not be satisfied.

> 
> * I'm not sure we need to report an error set of constraints that cannot
> be satisfied (vs only when none of the possible options can be
> satisfied)

For mandatory, we need to at least indicate that the mandatory constraints could not all be simultaneously satisfied.  I think it would be helpful to also receive, with that error message, at least one of the mandatory constraints that could not be satisfied.

> 
> * I think the type for MediaStreamConstraints member should be (boolean
> or MediaTrackConstraints) [rather than DOMString, and instead of
> including the dictionary keyword in the type]; the default values should
> be set to false;

Actually, I had heard someone (I think it was Anant) say that use of enums and booleans was deprecated in favor of DOMString.  If that's not true, and we should use booleans, then I'm happy to do so.
Anant?

> 
> * the type for the 1st member of MediaTrackConstraints also includes a
> buggy "dictionary" keyword; instead of a sequence<>, the second member
> should use an array

You are probably right.  I will check this.  The WebIDL spec is not very clear on some of this.

> 
> * I think the "abort these steps" in the getUserMedia algorithm doesn't
> match what we want when triggering an error (it should instead say "jump
> to the "failures" step)

Yes, I think you're right, but we need to adjust the steps after Failure to allow for a variety of different error messages rather than one message for everything.

> 
> Dom
> 
> 1. http://dev.w3.org/2011/webrtc/editor/getusermedia.html
> 2.
> http://dvcs.w3.org/hg/domcore/raw-file/default/Overview.html#error-types-table
> 
> 
> 
Received on Thursday, 7 June 2012 15:27:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:35 UTC