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

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

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Tue, 21 Jan 2014 12:32:04 -0500
Message-ID: <52DEAF14.7010707@bbs.darktech.org>
To: Justin Uberti <juberti@google.com>
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>
Your hard work is appreciated... Thanks again!


On 21/01/2014 1:01 AM, Justin Uberti wrote:
> 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 
> <mailto: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
>>     <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
Received on Tuesday, 21 January 2014 17:33:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:54 UTC