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

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