W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2014

Re: Summary of "What is missing for building real services" thread

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Fri, 17 Jan 2014 14:11:37 -0500
Message-ID: <52D98069.3070303@bbs.darktech.org>
To: Iñaki Baz Castillo <ibc@aliax.net>
CC: Alexey Aylarov <alexey@zingaya.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Tim Panton new <thp@westhawk.co.uk>

I don't know why you seem to feel so threatened by this proposal. I'm 
simply highlighting the fact that authors of native WebRTC applications 
and headless servers have a need for such a library. Whether I 
personally work on it or not does not invalidate that point. I'm 
bringing it to the community's attention and we'll see where it goes 
from here. If nothing happens, so be it, but at least interested parties 
see that they're not alone. We are in a better place to collaborate with 
each other once we see who else is interested.


On 17/01/2014 12:56 PM, Iñaki Baz Castillo wrote:
> Ok, do it.
> 2014/1/17 cowwoc <cowwoc@bbs.darktech.org>:
>> On 17/01/2014 12:42 PM, Iñaki Baz Castillo wrote:
>>> 2014/1/17 cowwoc <cowwoc@bbs.darktech.org>:
>>>> That's not what I'm talking about or asking for.
>>>> I'm not talking about "one library to rule all" but rather a reference
>>>> implementation by one of the vendors (I used Google as an example because
>>>> their implementation is already up on webrtc.org). Nothing would prevent
>>>> others from coming up with alternate libraries, or forking Google's.
>>>> I'm just saying that we should have *at least one* Native API that
>>>> mirrors
>>>> the Javascript API.
>>> No. We need specifications and standards. And if there is interest
>>> then smart guys will develop libraries/stacks based on those
>>> specifications (in different programming languages) by providing the
>>> API they want (because I'm very sure you have never requested to
>>> Asterisk and FreeSwitch, or Apache and Nginx, that they must offer the
>>> same API).
>> I'm saying the specification must lock down the JS API, and in parallel the
>> Native API should try to mirror the capabilities of the JS API but that is
>> an asynchronous process outside the scope of the specification.
>> To reiterate: the point of this API is *not* code portability but rather a
>> baseline or proof of concept showing *one way* to implement each one of the
>> features. Meaning: I am not asking all vendors to use the same API design,
>> but I am saying we should put out a *reference implementation* that shows
>> them an example of how it can be done.
>>> But you cannot tell to a W3C or IETF group that "we need a reference
>>> implementation". If the specs are good then you DO NOT need to learn
>>> from the code of others, nor to copy it.
>> Not true. Regardless of how good the spec is, it takes a non-trivial amount
>> of time/effort to implement the spec from the ground up and most of pieces
>> are not interesting from an innovation point of view. We should be able to
>> reuse code from the reference implementation (avoid reinventing the wheel)
>> for components that we don't care about, and focus our innovation/effort on
>> components *we do* care about. Right now it's an all-or-nothing thing, which
>> is a waste of the community's time.
>>> Honestly, if we need to use Google WebRTC code for every WebRTC
>>> project then that means that the specifications are BAD (how can it be
>>> different after mandating the usage of the painful SDP O/A?).
>> Again, you don't *need* it, but it's there for you if you want to reuse some
>> of the code. For example, the existence of an open-source database (e.g.
>> PostgreSQL) does not preclude the existence of commercial implementations
>> such as SQL Server.
>> Gili
Received on Friday, 17 January 2014 19:12:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:37 UTC