- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Thu, 18 Jul 2013 18:09:14 -0400
- To: Anne van Kesteren <annevk@annevk.nl>
- CC: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 18/07/2013 5:25 PM, Anne van Kesteren wrote: > On Thu, Jul 18, 2013 at 12:19 PM, cowwoc <cowwoc@bbs.darktech.org> wrote: >> Ideally, I shouldn't have to run a browser at all. Ideally, the >> specification should publish two APIs: JS and C/C++ (aka Native API) against >> the same use-cases. http://www.webrtc.org/webrtc-native-code-package >> mentions the latter, the specification completely ignores its existence. > I don't understand this. There's a JavaScript API being standardized. > The API maps to a protocol. If you want it in a different language, > implement the protocol and invent an API for it. There's no reason for > that to be a standardized solution. The browser API needs to be > standardized because users will all share that client, but the server > can be any client the server developer choses and it can have any > developer-facing API that server developer deems appropriate. This > philosophy is followed for the entire web platform stack. Good point. I'll take a step back. This entire discussion came about because I was afraid that the specification would mandate something that cannot be implemented (easily) by the Native API. So long as Google plans to release and support a WebRTC Native API (with a liberal license) on top of which the browser API is implemented, I don't foresee a problem. Thanks for clearing this up. Gili
Received on Thursday, 18 July 2013 22:09:56 UTC