Re: Improvements suggestion for DataChannels

>> * 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.
>
Ok, this should be added explicitly on the spec, as it is currently
written it could lead (as it hapened to me) that datachannel events
could be dispatched previously to that the PeerConnection object
signalingState get to stable. Strange thinking, I know, but the text
left open the door to it... :-/


>> * 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!
>
Reported :-)

https://code.google.com/p/chromium/issues/detail?id=347075


>> * 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.
>
I know, I only wanted to show the fact. Maybe we should consider to
add it now...


>> * 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).
>
I was trying to evade it just to check if there was any other
alternative with the current API than having PeerConnection objects to
list their DataChannels, and the fact was that there's no an easy or
clean way to do it, so the easiest was just to attach the DataChannels
list to the PeerConnection instance... just like an hypothetic
getDataChannels() method would do :-)


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


-- 
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
- Linus Tordvals, creador del sistema operativo Linux

Received on Wednesday, 26 February 2014 12:09:32 UTC