- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Fri, 10 Jan 2014 13:44:12 -0500
- To: Eric Rescorla <ekr@rtfm.com>
- CC: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Martin Thomson <martin.thomson@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 1/10/14 1:14 PM, Eric Rescorla wrote: > On Fri, Jan 10, 2014 at 10:03 AM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote: >> On 1/10/14 12:09 PM, Eric Rescorla wrote: >>> On Fri, Jan 10, 2014 at 9:04 AM, Jan-Ivar Bruaroey <jib@mozilla.com> >>> wrote: >>>> Good point about it being odd, tough I disagree it would be >>>> unrecoverable, >>>> as addStream would presumably push streams to a temporary list that >>>> createOffer discards (or prunes) if it fails. >>> And how am I to discover what went wrong? What a baffling API semantic. >> >> The createOffer error callback. It's an add/remove cart and checkout >> pattern. >> >> I'm just describing my understanding of the current API: We have add/remove >> methods that cannot fail and a createOffer method (aka "do it") that can. > Well, my point (and Martins and Adam's like a month ago) is that this > is busted. Busted == baffling, or busted == wont work? >>>> Should addStream(a), addStream(b), removeStream(a), createOffer() work? >>>> That >>>> would not be possible unless the validation was deferred (along with the >>>> rest of the actions) to createOffer. >>> Huh? The right thing here is simply to have AddStream() fail, which >>> doesn't >>> leave you in this state at all. >> >> Well, if it worked that way, then in your hardware-encoders-are-limited >> example, a client would have to be careful to remove any old stream from a >> stable stream FIRST before adding a new one, and not in any other order. > This seems like exactly the pattern that practically every other resource > allocation API I have ever seen uses. Except as Stefan points out, nothing really happens/matters until createOffer. > > -Ekr > .: Jan-Ivar :.
Received on Friday, 10 January 2014 18:44:40 UTC