Re: What is missing for building "real" services?

On 1/5/2014 3:59 PM, piranna@gmail.com wrote:
>
> I have reminded myself another issues regarding specially to DataChannels:
>
> * It is too much cumbersome to create a DataChannel-only connection 
> and there are too much concepts related to it: SDP, offer, answer, 
> PeerConnection objects, signaling channel (common sense says, if you 
> already has a channel to comunicate between both peers, why you would 
> create another one)... Too much complicated and anti-intuitive.
>

Signaling often (almost always) is relayed by a 3rd party, perhaps even 
cut-and-paste in IRC.  The SDP (and ICE, etc) lets the two sides 
negotiate a direct p2p connection.  Plus pure p2p data connections 
simply falls out of the work done to provide audio and video (and data) 
p2p.  If you're building a pure data application, most of these things 
(SDP, etc) don't need to be understood or examined, just treated as 
black boxes of setup data to be exchanged.  (The fly in the ointment is 
as you mention later Trickle ICE, though there are reasons for it even in .)

> * Also, you need to deal with candidates and Trickle ICE (the epithome 
> of anti-intuitive things for a web developer, my DataChannel-polyfill 
> developed using the firts specs didn't need it and was fairly easy to 
> understand how it worked and straighforward to implement, but adding 
> support for candidates was a nighmare both on usage and 
> implementation), that although you can override it just waiting all 
> candidates to be generated when onicecandidate event gets null, it is 
> more like a hack that a real solution, while there should be an option 
> about to use Trickle ICE or instead receive the full SDP when calling 
> createOffer() and createAnswer(), that in that case would simplify 
> (somewhat) it's usage.
>

This touches a fundamental area of contention in the spec - complexity 
versus capability.  For audio/video (and also data), speed of 
negotiating a connection may be a very important thing, and trickle can 
help here.  However, especially for non-interactive acceptance (which 
will be much more common with data-only connections), the advantage of 
trickling candidates goes down.

> * There's no way to get a list of all the DataChannels being used on a 
> PeerConnection object, while there are lists for the audio & video 
> streams. DataChannels specification is almost one and a half years 
> old, why it hasn't been added yet?
>

The API for adding and removing datachannels is not the same as for 
adding and removing MediaStreams, which is part of the reason.  To be 
honest, no one has seriously proposed a use-case for needing it. Given 
the low likelihood of an application needing this, letting the 
application keep the list itself (if it needs to) seems reasonable.

> * Finally, nothing has been talked officially about add support for 
> PeerConnection inside WebWorkers (specially SharedWorkers or the 
> upcoming ServiceWorkers), when it would be useful for maintain 
> connections open or to do transfers on background.
>

This has been mentioned.  This is not necessarily simple, though I agree 
there are significant advantages to making it possible.  I would not 
expect it in the first iteration of WebRTC/PeerConnection.

> 2014/1/2 Svein Yngvar Willassen <svein@comoyo.com 
> <mailto:svein@comoyo.com>>:
> > I'd second most of what has been said in this thread so far. You can 
> build a real service with WebRTC. Our service appear.in 
> <http://appear.in> shows that. It is also true that many of the issues 
> we've previously had to work around have disappeared with newer 
> browser versions. That being said, some issues remain. The following 
> are common issues / requests we get from our users that we feel must 
> be addressed by the browser. (Either by spec or just browser 
> implementations):
> >
> > - Missing echo cancellation and other audio issues, particularly 
> when there are more than two participants in a conversation. (Audio 
> should be more stable / higher prioritized than video, currently it 
> often seems opposite.)
> > - NAT traversal and connection stability issues.
> > - Screen sharing with better quality which also works in other 
> browsers than Chrome.
> > - Ability to renegotiate streams, for example lowering image 
> resolution without stopping and starting the stream.
>

This should be possible without any renegotiation (at least from the 
sender side) by manipulating the MediaStream or via the to-be-defined 
"doohickey", I believe.


-- 
Randell Jesup -- rjesup a t mozilla d o t com