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

I agree about workers, while webworkers probably won't work since destroyed while page is reloaded , it makes sense to check other workers if they are suitable to maintain PeerConnection or DataChannel in background between page reloads on the same website.

-Alexey

> On Jan 6, 2014, at 0:59, "piranna@gmail.com" <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.
> 
> * 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.
> 2014/1/2 Svein Yngvar Willassen <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 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
> >
> >
> >
> 
> 
> -- 
> "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