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

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 
> <mailto: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
>         <mailto:cowwoc@bbs.darktech.org>>:
>
>             On 17/01/2014 12:42 PM, Iñaki Baz Castillo wrote:
>
>                 2014/1/17 cowwoc <cowwoc@bbs.darktech.org
>                 <mailto: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
>                     <http://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
>
>
>
>
>
>