Re: Teleco Integrators vs Web Developers vs Browser Implementers

The appropriate proposal is forthcoming.
_____________
Roman Shpount


On Fri, Jun 28, 2013 at 6:30 PM, piranna@gmail.com <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>:
> > 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> 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
>