- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Wed, 24 Jul 2013 00:58:40 -0400
- To: Eric Rescorla <ekr@rtfm.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <51EF5F00.1050003@bbs.darktech.org>
On 23/07/2013 11:59 PM, Eric Rescorla wrote: > We need more frequent webrtc-public IRC meetings > > I (and I suspect others) prefer con calls to IRC meetings. I don't > think this presents an undue > barrier to entry. No problem. Please announce these on webrtc-public with instructions on how to join and we will happily meet you there. > > and more Web Developer representation (ideally unaffiliated with > any business interest). A recurring theme I keep on bringing up is > that we have an insufficient number of active Web Developers in > the Working Group and official meetings. I've asked Stefan > recently (I don't think he's had the chance to respond yet) and > I'll ask you the same: what is the Working Group's plan to rectify > this? > > > I'm not sure what you suggest we do. This is a volunteer effort and > the list > is open to anyone. That said, this seems to me to be a fairly > representative > WG in terms of non-company engagement when compared to the other > two W3C WGs I am involved in (WebAppSec and peripherally WebCrypto). > > > Both Google and Mozilla have mailing lists where there is active > discussion > from Web Developers and I think the people from both organizations try to > take that feedback onboard. of course that feedback still gets filtered > through the representatives from those organizations, but there's nothing > stopping developers from posting directly here. The solution I am leaning towards is divorcing WebRTC from Telecoms and Web Developers. This sounds like the easiest solution. In that case I would expect Browser Vendors to agree to a common API that is interoperable across all browsers and (key point!) does not unduly influence design decisions of APIs placed on top of it. From a decision-making process point of view, things should move a lot faster because each one of us will be negotiating with similarly-minded players. I would then layer a Telecom API and Web Developer API on top of the Browser API. The Telecom API would plug in SDP as a transport layer. The Web Developer API would use another transport layer. Both implementations would translate from/to Constraints on top of different transport layers. Figure out which API components need to be plugable (e.g. signaling). That's the goal, we can have more concrete discussions on how to achieve that. Gili
Received on Wednesday, 24 July 2013 04:59:31 UTC