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



-----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 Wednesday, 18 July 2012 21:54:14 UTC