W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2013

Re: Another API issue: addStream has no callbacks

From: Justin Uberti <juberti@google.com>
Date: Mon, 25 Feb 2013 18:13:09 -0800
Message-ID: <CAOJ7v-2+hfAac9Wy2Q1ROPJXUHe17Fqot5ccu68QRD-WzxAsRA@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
There may be reasons for addStream to fail (e.g the PeerConnection has been
closed), but I don't think exhausting encoders is one of them. Any
resources are not reserved until createOffer/setLocal.

addStream simply adds the supplied stream to the list of local streams
known to the PeerConnection.

On Mon, Feb 25, 2013 at 2:08 PM, Harald Alvestrand <harald@alvestrand.no>wrote:

> On 02/25/2013 10:13 PM, Adam Roach wrote:
>> Sometimes it seems like I'm screaming into the void by posting the issues
>> we're actually running into implementing this stuff, but here's another
>> problem we've uncovered with the currently defined API:
>> addStream() can plausibly fail, and some of those failures can occur
>> asynchronously. Examples of such failures include exhausting encoders of
>> the indicated type (e.g., I might have a device with only one hardware
>> video encoder).
>> While we could allow these calls to succeed and then return an error when
>> the application attempts to take further action (e.g., createOffer or
>> createAnswer), I think delaying such errors until later will surprise and
>> befuddle application developers.
>> For these reasons, I would propose the addition of success and error
>> callbacks to addStream.
>> /a
>>  My standard questions for callbacks added to existing APIs:
> - Mandatory or optional? (we've preferred mandatory before)
> - Before or after the optional "constraints" interface?
> And for curiosity - what were the plausible failures?
> (I wasn't able to figure out a plausible failure for getStats either
> before we implemented it and found one...)
Received on Tuesday, 26 February 2013 02:13:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:41 UTC