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