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

On Wed, Jul 18, 2012 at 3:18 PM, Harald Alvestrand <harald@alvestrand.no>wrote:

> 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/**1nfA1ElWed5PPR4nqenEkxNMMLRfzA**
>>> sh1yMLe8yRcns8/edit#<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
>
>
>
Also more importantly for setRemote is that you want to make sure the
SessionDescription has been processed/handled before calling createAnswer.

-- 
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
And yes, I have to include the above in every outgoing email according to
EU law.