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

Re: Improvements suggestion for DataChannels

From: Randell Jesup <randell-ietf@jesup.org>
Date: Wed, 26 Feb 2014 03:20:06 -0500
Message-ID: <530DA3B6.8060408@jesup.org>
To: public-webrtc@w3.org
On 2/7/2014 5:47 PM, piranna@gmail.com wrote:
>
> Sorry for the delay, I have had some busy weeks on work and with the 
> exams, and also I wanted to test in profundity the usability of 
> DataChannels as how they are currently defined on the spec.
>
> After doing that tests, I have learned several things:
>
> * if you created some DataChannels on one side (and probably also if 
> you added some streams, too), only this side will have them since the 
> ondatachannel event is only dispatched after the PeerConnection 
> objects signalingState change to 'stable', allowing to use this trick 
> to know what endpoint initiated the connection (a feature that, by the 
> way, would be lost if a datachannel event were dispatched on the 
> creator endpoint as I proposed... so I've changed my mind on this point).
>

Right.

> * when the ondatachannel event is dispatched, at least on Chrome v33 
> the DataChannel readyState attribute was 'open' instead of 
> 'connecting' as according to the spec, and not only that, it was later 
> dispatched the DataChannel 'open' event. (This lead me a full day of 
> debugging last weekend...)
>

This simply sounds like a bug - please report to Chrome!

> * due to the previous point, I think seriously that DataChannel (and 
> by extension, all WebRTC classes) should support promises to prevent 
> this kind of situations.
>

This discussion was had in the MediaCapture context some time ago; we 
decided not to tie the two at this time - promises can be added at a 
later point if we want, and I believe the current API can be wrapped 
with promises if so wished.

> * as you predicted, since I was able to create a shim to add support 
> for PeerConnection.getDataChannels(), I have been able to do it at 
> application level and also in a more optimized way (just store the 
> DataChannels I was interested to, and just have a reference for them 
> when the PeerConnection got stable without needing it later), but the 
> problem is about how to easily identify what DataChannels are from 
> what PeerConnection object, and since I was not able to attach them 
> using closures (I'm sharing a lot of code between sender and receiving 
> peers) the only solutions I found feasable were to use a hash of 
> arrays using as key an ID for each peer... or just add the list of 
> DataChannels to the PeerConnection instance, that it's the easiest way 
> but also the one that I was trying to evade.
>

Why were you trying to evade it?  It seems the obvious choice to me (but 
I'm not a day-in, day-out JS programmer).

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

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Received on Wednesday, 26 February 2014 08:21:54 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:38 UTC