W3C home > Mailing lists > Public > public-media-capture@w3.org > July 2013

Re: Use-case: Auditing

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Thu, 18 Jul 2013 18:09:14 -0400
Message-ID: <51E8678A.5070307@bbs.darktech.org>
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.

Received on Thursday, 18 July 2013 22:09:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:18 UTC