Re: Summary of desired spec updates (Was: summary of some ongoing discussions)

at some meeting in the not to far future, we should probably spend a bunch of time discussing how errors are reported. AFAIC, the error handling in the current spec is largely missing but it seemed more important to nail down the sunny day cases before sorting out all the error cases. 

On Jul 18, 2012, at 3:50 PM, Li Li <Li.NJ.Li@huawei.com> wrote:

> 
> 
> -----Original Message-----
> From: Li Li 
> Sent: Wednesday, July 18, 2012 5:48 PM
> To: 'Harald Alvestrand'
> Subject: RE: Summary of desired spec updates (Was: summary of some ongoing discussions)
> 
> What is the parameter for RTCErrorCallback?
> 
> In the current editor's draft, the parameter is a DOMString:
> 
> <quote>
> callback PeerConnectionErrorCallback = void (DOMString errorInformation)
> 
> 
> DOMString errorInformation
>    Information about what went wrong. Open Issue: How does this work? Is it human readable? I18N? ENUM? 
> 
> TODO: Open Issue: should this be defined as event like NavigatorUserMediaErrorCallback in getusermedia
> </quote>
> 
> I think it's a good idea to define a structured event so web application can check it efficiently for errors, especially now that the callback is used in 4 methods.
> 
> Following the suggestion in the draft, something like this may work:
> 
> [NoInterfaceObject]
> interface RTCCallbackError {
>    const unsigned short XYZ = 1; // code to be defined for each method
>    // more code to follow...
>    readonly attribute unsigned short code; // one of the defined code
>    readonly attribute DOMString info;      // human readable information
> };
> 
> 
> Thanks.
> Li
> 
> -----Original Message-----
> From: Harald Alvestrand [mailto:harald@alvestrand.no] 
> Sent: Wednesday, July 18, 2012 9:19 AM
> To: public-webrtc@w3.org
> Subject: Re: Summary of desired spec updates (Was: summary of some ongoing discussions)
> 
> On 07/17/2012 04:38 PM, Stefan Hakansson LK wrote:
>> On 07/16/2012 08:45 PM, Justin Uberti wrote:
>>> I've tried to summarize all of these changes and the discussions of the
>>>  past few weeks into a concrete proposal for an updated API. This
>>> proposal is attached, and is also available at
>>> https://docs.google.com/document/d/1nfA1ElWed5PPR4nqenEkxNMMLRfzAsh1yMLe8yRcns8/edit#. 
>>> 
>> 
>> Justin, thanks for the input. I appreciate concrete proposals on how 
>> to solve issues we have identified!
>> 
>> Personally I think what you propose seem to make sense. Some things 
>> have not been discussed that much yet, but I would be fine if they 
>> were included in the Editor's draft (which of course can change based 
>> on the discussions).
>> 
>> The only thing that I immediately think could perhaps have another 
>> solution is the async callback to setLocal/setRemote. I think what we 
>> want to accomplish is a way to handle errors (you are not going to do 
>> anything on the success callback, right?), and perhaps we should have 
>> a more generic error reporting mechanism. That said, I have no problem 
>> using the async callback in the Editor's draft (if there is need to 
>> specify a way for error reporting) for the time being.
> 
> The thing about a success callback is that it allows you to know 
> specifically that you won't get an error callback later, so that (for 
> instance) you can remove the UI components that would display this 
> particular type of error.
> 
> There have been systems before that did RPCs with just an error return 
> (silent success) or just a success return (silent error); they proved 
> very confusing to use, and were not popular.
> 
> If an app really doesn't care about one of the callbacks, it can just 
> not provide any handler for that callback. I think that is flexibility 
> enough.
> 
>                   Harald
> 
>

Received on Monday, 13 August 2012 15:17:18 UTC