Re: Teleco Integrators vs Web Developers vs Browser Implementers

+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

Received on Friday, 28 June 2013 22:31:43 UTC