Re: Teleco Integrators vs Web Developers vs Browser Implementers

Roman,

     I empathize with your desire to simply throw together a better API 
but you're unlikely to get it right without the requirements (everyone's 
use-cases). We're not trying to throw out the telecom's requirements, 
rather add our own use-cases alongside them.

     A quick answer regarding why the user is exposed to an opaque blob: 
the specification makes a conscience decision to omit the bootstrap 
process (aka signaling). WebRTC generates some blob and it is up to you 
to somehow transfer it from one peer to another in order to establish 
the connection. If the bootstrap process was handled by WebRTC then 
obviously you wouldn't see this blob at all.

     Why does the specification omit the bootstrap process? I'm sure 
there is a good reason for it, but until we see their list of use-cases 
we won't know.

Gili

On 28/06/2013 6:34 PM, Roman Shpount wrote:
> The appropriate proposal is forthcoming.
> _____________
> Roman Shpount
>
>
> On Fri, Jun 28, 2013 at 6:30 PM, piranna@gmail.com 
> <mailto:piranna@gmail.com> <piranna@gmail.com 
> <mailto:piranna@gmail.com>> wrote:
>
>     +1 for everything. Would it be a solution start writing "dream code"
>     and start designing the API from there? It seems we are almost all
>     not-telecom savy here, but maybe the few ones that are on the list
>     could fix or wrong concepts... What do you think?
>
>     2013/6/29 Roman Shpount <roman@telurix.com
>     <mailto:roman@telurix.com>>:
>     > I think points #2 and #3 in Gili's email are putting focus on
>     the completely
>     > incorrect problem. The problem is not about Teleco Integrators
>     vs Web
>     > Developers vs Browser Implementers. I think this distinction is
>     completely
>     > bogus and just a sign of a badly designed API. The problem we
>     are dealing
>     > here is that this API is designed using inappropriate concepts
>     and logic. It
>     > takes telecom concepts like offer/answer and SDP and tries to
>     hide them
>     > behind some "easy to use" interface. In reality all this does is
>     uses
>     > concepts that are artificial and unneeded. The functionality I
>     need to
>     > implement (as a developer or as teleco or as implementer) is to
>     capture
>     > audio or video and send it to the remote party. Or alternatively
>     I want to
>     > receive audio or video from remote party and play it out
>     locally. Where is
>     > offer and answer in this scenario? Where are session
>     descriptions? The
>     > things I would understand are local and remote addresses, encryption
>     > settings, and media encoding formats. Each of this should be
>     controlled by
>     > me and not left to the browser to negotiate based on some opaque
>     blob which
>     > I am not supposed to look at. Since we do not express API in the
>     expected
>     > and understandable terms, we end up with a lot of problems such
>     unneeded
>     > complexity (state machine with queued asynchronous offers and
>     answers),
>     > inability to implement any scenarios except the basic ones
>     provided in
>     > examples (covered in
>     draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00)
>     > and complete inability to debug things if something breaks. Just
>     think about
>     > it, either everything would automagically work all the time, or
>     every time I
>     > need to debug something (once again I can be web developer or
>     implementer or
>     > integrator) I need to look at the SDP, interpret it, and see
>     what is being
>     > exchanged. From my point of view this is a complete failure for
>     all target
>     > audiences.
>     > _____________
>     > Roman Shpount
>     >
>     >
>     > On Fri, Jun 28, 2013 at 5:35 AM, Adam Bergkvist
>     > <adam.bergkvist@ericsson.com
>     <mailto:adam.bergkvist@ericsson.com>> wrote:
>     >>
>     >> Thanks for a great summary.
>     >>
>     >> (no new subject line (yet); just some high-level comments)
>     >>
>     >> On 2013-06-27 16:19, Gili wrote:
>     >>
>     >>>  2. The WebRTC API needs to focus on normal web developers,
>     not not
>     >>>
>     >>>     telecom experts: The conversation on this mailing list is
>     unduly
>     >>>     skewed in favor of telecom experts which make up a tiny
>     minority of
>     >>>     WebRTC end-users. We need to find a way to collect
>     feedback from the
>     >>>     Javascript community at large in order to ensure that the API
>     >>>     facilitates their use-cases. The proliferation of WebRTC
>     SDKs for
>     >>>     end-users (the conference was full of them) is a strong
>     indication
>     >>>     that there is a gap to be filled.
>     >>
>     >>
>     >> I would love to have this as one of our main targets. Even
>     though WebRTC
>     >> brings something new to the web platform, web developers should
>     feel as much
>     >> at home as possible.
>     >>
>     >>>  7. Use-cases, use-cases, use-cases: "Tell us what is wrong,
>     not how to
>     >>>
>     >>>     fix it". You are a lot more likely to get traction for
>     your problems
>     >>>     if you help us understand your use-cases then trying to
>     argue for
>     >>>     change for its own sake. On the flip side for
>     specification editors,
>     >>>     I encourage you to actively engage posters (ask for these
>     use-cases)
>     >>>     instead of ignoring discussion threads ;)
>     >>
>     >>
>     >> Very true.
>     >>
>     >> /Adam
>     >>
>     >
>
>
>
>     --
>     "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
>
>