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

getUserMedia WebIDL feedback

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Mon, 04 Jun 2012 16:01:27 +0200
Message-ID: <1338818487.3217.243.camel@altostratustier>
To: public-media-capture@w3.org
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

* 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'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)

* 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;

* 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

* 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)

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 Monday, 4 June 2012 14:02:04 UTC

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