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

On 07/18/2012 03:33 PM, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote:
> On Wed, Jul 18, 2012 at 3:18 PM, Harald Alvestrand <harald@alvestrand.no
> <mailto: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.

Ah, that is a good point. What you are saying is that "createAnswer" 
must (to be sure things work) be executed in the success callback of 
"setRemote('the incoming offer');".

>
> --
> 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.

Received on Thursday, 19 July 2012 12:07:47 UTC