- From: Eric Rescorla <ekr@rtfm.com>
- Date: Fri, 10 Jan 2014 10:14:39 -0800
- To: Jan-Ivar Bruaroey <jib@mozilla.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 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. > >>> 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. -Ekr
Received on Friday, 10 January 2014 18:15:48 UTC