Re: Another API issue: addStream has no callbacks

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