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

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

From: Justin Uberti <juberti@google.com>
Date: Fri, 17 Jan 2014 16:07:57 -0800
Message-ID: <CAOJ7v-24vidwTeAc2bJ1s1FuXQ2okLCvz+tsbgzd_-R02+bt9w@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Cc: Iñaki Baz Castillo <ibc@aliax.net>, Alexey Aylarov <alexey@zingaya.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Tim Panton new <thp@westhawk.co.uk>
We maintain native API bindings for PeerConnection for Android (Java) and
iOS (ObjC). They sits atop a C++ PeerConnection implementation (which also
powers the JS impl in Chrome), and all mirror the W3C API fairly well. Is
this not sufficient?

On Fri, Jan 17, 2014 at 11:11 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

> Iñaki,
> 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.
> Gili
> 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 Saturday, 18 January 2014 00:08:45 UTC

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