Teleco Integrators vs Web Developers vs Browser Implementers

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
>
>