Re: Another API issue: addStream has no callbacks

Based on Adam Bergkvist's comment recently that a closed PeerConnection
does not null out its state, I'm not sure if my previous comment that
addStream needs to fail on a closed PeerConnection is true either.


On Mon, Feb 25, 2013 at 6:13 PM, Justin Uberti <juberti@google.com> wrote:

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