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

Re: New error events

From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 3 Mar 2013 16:48:25 -0800
Message-ID: <CABcZeBNRZA3-09P6x1PvKXSeCDC7LzvhnPVJ-cn+tNL1jk3Tqg@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Cc: Jim Barnett <Jim.Barnett@genesyslab.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Sun, Mar 3, 2013 at 4:16 PM, Justin Uberti <juberti@google.com> wrote:

> We'll also need some way to indicate whether a given error is a fatal
> error, or just a warning, so the app knows what to do.
>
> For example, a DTLS handshake error is likely fatal, whereas failure to
> create UDP sockets might not be.
>

Yeah. Though in the case we are looking at, it generally is, because it
means we
don't have network ports for one of our components.

-Ekr


>
> On Sat, Mar 2, 2013 at 3:18 PM, Justin Uberti <juberti@google.com> wrote:
>
>> Yeah, I was thinking the same thing the other day, in the context of
>> "internal error". This stuff happens and robust apps are going to want to
>> at least phone home about this.
>>
>> Do you have a suggestion for the enums (generic error, transport failure,
>> security failure)?
>>
>>
>> On Sat, Mar 2, 2013 at 1:51 PM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote:
>>
>>> We need a similar set of error events for recording. It would be good to
>>> find a way to do this without creating a lot of new classes. Could we
>>> define a single that gUM, webRTC, recording and takePhoto could use?
>>> Jim
>>>
>>> On Mar 2, 2013, at 9:17 AM, "Eric Rescorla" <ekr@rtfm.com> wrote:
>>>
>>> > Hi folks,
>>> >
>>> > I'm starting to come to the conclusion that we need some ways
>>> > to implement error notification as distinct from either
>>> setLocal/setRemote
>>> > or state notification. Here are some examples of events that don't
>>> > seem to me to have a logical way to report to the programmer:
>>> >
>>> > - ICE allocation failed (e.g., couldn't actually allocate sockets for
>>> > each component.) Obviously, you could report that allocation
>>> > is *done* but it's not like a naive application is going to notice
>>> > that candidates are missing.
>>> >
>>> > - DTLS-SRTP handshake failed.
>>> >
>>> > - The ever-famous "internal error".
>>> >
>>> > I would suggest that we have some sort of "onerror" event, perhaps
>>> > with a numeric error enum and a string that is explanatory.
>>> >
>>> > Thoughts,
>>> > -Ekr
>>> >
>>> >
>>> >
>>>
>>>
>>>
>>
>
Received on Monday, 4 March 2013 00:49:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:32 UTC