Re: RTCError, DOMError, and... what happened?

On Sun, Oct 13, 2013 at 9:57 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:
> On 12/10/2013 1:33 PM, Harald Alvestrand wrote:
>
> Agreed.
>
> Suggestion: we should define
>
> [Constructor(DOMString name, optional DOMString message = "")]
> interface RTCError {
>   readonly attribute DOMString name;
>   readonly attribute DOMString message;
> };
>
> with the comment
>
> "We intend to use DOMError as soon as there is a stable reference for
> DOMError that contains both the name and the message field".
>
> We should also list the "name" values we use explicitly, and note which ones
> are currently part of the DOM specification.
>
> It seems that given that we're publishing a W3C specification, we must
> reference the W3C version of the spec, not the "living spec" - Anne might be
> able to say what the schedule is like for that.
>
>
>     Can't you have RTCError extend DOMError?

Problem is: extend which DOMError specification?

I found:
http://www.w3.org/TR/DOM-Level-3-Core/core.html#ERROR-Interfaces-DOMError
http://www.w3.org/TR/domcore/#domerror
http://dom.spec.whatwg.org/#domerror

Plus - as Anne says - this is all getting re-evaluated as we speak and
is in flux.

I agree that it makes most sense for us to have RTCError stand-alone.
Maybe the note should be even more generic and say that we will fit
RTCError within the new DOM4 error handling framework as soon as such
a framework has been decided on. For now, all we expect is that a
RTCError provides a name and a message.

Are we going to follow the "name" field being camelcased?

Cheers,
Silvia.

Received on Sunday, 13 October 2013 00:11:56 UTC