- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Fri, 17 Jan 2014 07:05:35 +0100
- To: public-media-capture@w3.org
On 01/02/2014 04:39 PM, Jim Barnett wrote:
> Randy,
> The description of error handling needs to be updated. It will use MediaError from the latest Media Capture editors' draft, or something similar to it. The editors don't think that we should refer to DOMError until it is stable, but we haven't discussed on the list exactly what to do with MediaRecorder yet. This may depend on whether MediaRecorder implements Constrainable or not. MediaError has a 'constraintName' attribute. It will be useful if MediaRecorder implements Constrainable, but not otherwise.
No matter what we do, MediaRecorder should use an error structure that
has a message field.
I think that's pretty clear; even later (and earlier!) versions of
DOMError have it.
> Jim
>
> On Jan 1, 2014, at 10:02 PM, "Randy Lin" <rlin@mozilla.com> wrote:
>
>> Hi All,
>>> From this spec
>> https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/MediaRecorder.html#idl-def-RecordingErrorNameEnum.xOtherRecordingError
>> On 5. Error Handling section,
>> Some exceptions require additional information and should pass through message attribute via DOMError interface,
>> like
>> --OutOfMemory The UA has exhaused the available memory. User agents SHOULD provide as much additional information as possible in the message attribute.
>> --OtherRecordingError Used for an fatal error other than those listed above. User agents SHOULD provide as much additional information as possible in the message attribute.
>>
>> But refer to the 3.2 Interface DOMError
>> http://www.w3.org/TR/2012/WD-dom-20121206/#interface-domerror
>>
>> interface DOMError {
>> readonly attribute DOMString name;
>> };
>>
>> We don't have the message attribute for exceptions.
>> Is it possible to create new interface for media recorder API?
>> -------------------------------------
>>
>> -rlin
>>
>
Received on Friday, 17 January 2014 06:06:04 UTC