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

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