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

OK, thanks for reviewing it.

Regarding some of the other comments - there is clearly demand from
developers to not have to write completely different code on web, Android,
and iOS. So we have tried to provide similar APIs on each of these
platforms. The API is not perfect, but it will get better over time.



On Sat, Jan 18, 2014 at 3:01 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>  Hi Justin,
>
> You're right. I just reviewed the Native API once more (I haven't done so
> in a few months) and this looks like what I'm asking for.
>
> Thanks,
> Gili
>
>
> On 17/01/2014 7:07 PM, Justin Uberti wrote:
>
> 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
>>>>
>>>
>>>
>>>
>>
>>
>
>