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

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

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Fri, 17 Jan 2014 18:56:34 +0100
Message-ID: <CALiegfnJdShyfx-YuJtnRMT-TywoYoTKL_oWGt1Mg3-3mzgoaw@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Cc: Alexey Aylarov <alexey@zingaya.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Tim Panton new <thp@westhawk.co.uk>
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

Iñaki Baz Castillo
Received on Friday, 17 January 2014 17:57:21 UTC

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