- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Fri, 29 Mar 2013 18:40:48 +1300
- To: Jim Barnett <Jim.Barnett@genesyslab.com>
- Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
- Message-ID: <CAOp6jLYYvFrgdG0_Q6NUP4eBp15GH2AYjc_XqNEA8Q1pAizM2g@mail.gmail.com>
I assume your attachment matches what's checked into https://dvcs.w3.org/hg/dap/raw-file/default/media-stream-capture/MediaRecorder.html . > void start (optional long? timeslice); I don't think you want the ? there. The text for imageHeight/imageWidth/mimeType says "the initial value will be a platform-supplied default". It seems better for the initial value to be defined, e.g. 0 and the empty string. When and how often do they change to a different value? The spec needs to say. The utility of stop/start/pause/resume events seems questionable. These happen in response to method calls on the MediaRecorder, so authors already know when these things are happening. Are there use-cases where these events are useful? Separate error and warning events seems unnecessary. Other Web APIs don't use warning events. Web developers generally receive warnings via some UA-specific developer tool interface. If an actual Web app can't use the information, the API shouldn't be there. And generally, if you're not sure an API is needed, it shouldn't be there. The members of RecordingSettings should not be nullable. As dictionary members, they're all always optional. AvailableSettings members should probably always be present, therefore AvailableSettings should not be a dictionary. In fact it's unclear why bundling these members together into an object is helpful. Why not provide a separate attribute on MediaRecorder for each "available setting" that needs to be exposed? For MIME types, instead of a list why not follow HTMLMediaElement and offer a canRecordType method? Seems easier to use than asking apps to scan a list. Also, it's more flexible since MIME types can contain information like codecs and other recording parameters, and you wouldn't want to make a list enumerating every supported recording configuration. Is it really necessary to export the minimum and maximum width and height? I think it would be simpler and just as workable to let the author request a width and height and let the user-agent automatically clamp them to fit implementation limits (preserving aspect ratio I suppose). Rob -- q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"
Received on Friday, 29 March 2013 05:41:15 UTC