On 1/10/14 12:14, 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. For the record, I agree with EKR, Martin, and even my earlier self. I don't agree with the prospect that we should defer errors to some point significantly later than is necessary. I mean, if an application wants to do something like add eight video streams, up to the maximum that can currently succeed, then the semantics we're proposing would allow determination of that limit by adding eight streams and seeing if any of them fail. What you're proposing is that developers would try to add eight, see that fail, and then either perform some kind of linear backoff or binary search to determine what the number of streams they can successfully add might be. There's a pretty well worn design principle in protocol development that you don't combine lots of operations into a single command/response sequence unnecessarily, since it forces the operations need to succeed or fail atomically. This seems like a natural translation of that principle into API design. -- Adam Roach Principal Platform Engineer abr@mozilla.com +1 650 903 0800 x863
Received on Friday, 10 January 2014 21:37:34 UTC