W3C home > Mailing lists > Public > public-webrtc@w3.org > October 2013

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sun, 13 Oct 2013 11:11:08 +1100
Message-ID: <CAHp8n2=Z6-Q+zFNOYssoRR0263R=0+njOGiqrH06jB5CO63kJA@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Cc: public-webrtc <public-webrtc@w3.org>
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:

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?

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:51 UTC