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

On quite a few of these, coming up with specific proposals that explain:

- Why it's needed
- How it could be done

would greatly increase the chances of something happening.
It's very nice to ask that "someone do something"; it's much better to 
actually do it.

On 01/05/2014 09: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.
>

On this aspect, however, I think the answer is "live with it". It's just 
the way the design is.

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

Someone who actually understands the *Workers model needs to propose 
something here.
It's been suggested that "all" we need to do is to make MediaStreams 
and/or MediaStreamChannels transferable objects - but I suspect there 
are devils in the details here.

> 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.
> > - Ability to record streams.
> > - Support in iOS and the Safari and IE browser. (Probably little the 
> WebRTC community can do about this.)
> >
> > --
> > Svein Willassen, ph.d.
> > Tech Lead, appear.in <http://appear.in>
> >
> >
> >
>
> -- 
> "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
>