Re: Improvements suggestion for DataChannels

On 2014-01-13 08:48, piranna@gmail.com wrote:
>> I'm hesitant to do these changes since they don't enable, or make it
>> significantly easier to enable, anything that's not possible with the
>> current API. I see these as convenience things that some developers find
>> useful; and as you show, it's rather easy to derive these features from the
>> information provided by the current API. I would be more concerned if you
>> couldn't write a shim for this in 50, or so, lines of code.
>>
> I absolutly agree that they could be viewed as convenience things
> useful for developers (that are the ones that they will use the API at
> the last point!), but for example, the list of current DataChannels is
> also to make the API homogeneous regarding to the fact that you can
> get a list of the current local and remote streams, list that you
> could also be able to build externally counting the calls to
> addStream() and listening to the addstream event.
>

There's a difference here because the APIs are different in many ways. 
For example, you add a MediaStream, created somewhere else, to an 
RTCPeerConnection. When you don't want it to be associated with this 
RTCPeerConnection anymore, you remove it. So you're working with a list 
of associated streams. On the other hand, you create DataCannels with a 
factory method. A DataChannel can only be associated with the 
RTCPeerConnection that created it and it can't live on it's own (like a 
MediaStream). Having a list of DataChannels would change the rules for 
garbage collecting the object. We would need a corresponding 
destroy()-method on the RTCPeerConnection or similar. I don't think we 
want to go there.

/Adam

Received on Tuesday, 14 January 2014 08:17:20 UTC