W3C home > Mailing lists > Public > public-webrtc@w3.org > March 2014

Re: Improvements suggestion for DataChannels

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Mon, 3 Mar 2014 12:01:55 +0100
Message-ID: <53146123.3050705@ericsson.com>
To: "piranna@gmail.com" <piranna@gmail.com>, Randell Jesup <randell-ietf@jesup.org>
CC: public-webrtc <public-webrtc@w3.org>
On 2014-02-26 13:08, piranna@gmail.com wrote:
>>> So as conclussion, I have to admit that with the current specification
>>> >>it's possible to achieve the same purposses that my propositions about a) an
>>> >>indicator about who started the PeerConnection and the creation of the
>>> >>DataChannel, and b) a way to get the list of DataChannels of a
>>> >>PeerConnection instance and they are just simple syntactic sugar, but the
>>> >>fact is that the current spec API doesn't allow an easy nor elegant way to
>>> >>get that info, so I still believe that this functionality should be added,
>>> >>in the worst case to be more homogeneous with the PeerConnection streams
>>> >>related methods counterpart.
>>> >>
>> >
>> >I don't have anything in particular against being able to list the channels.
>> >I will note that in a "proxy" case where both sides connect to an
>> >intermediary/central-server, both sides (or all sides) may believe they're
>> >the creator (or offerer) or that the other side was, so it can be dangerous
>> >to make generic assumptions there - but this is largely just a caveat to the
>> >application to be cautious. The strongest argument against is that the
>> >functionality is already (as you say) implementable in userspace for those
>> >who need it without major trouble.
>> >
> As you said, it's an application level issue, so being the developer
> cautious on this use case it's enough. And regarding to the list of
> DataChannels, as I show you it's possible to do it, but it would be
> easier and cleaner to have it natively.

I still think we should avoid having a list of DataChannels on the 
PeerConnection object since we don't have a counterpart for 
PeerConnection.removeStream() for DataChannels. This means that, to make 
it possible to ever garbage collect DataChannel objects, 
DataChannel.close() would need to have a side effect that removed the 
channel from its PeerConnection or we would have to add a new method to 
do that. Both are strange an unmotivated IMO.

Received on Monday, 3 March 2014 11:02:19 UTC

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