- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Fri, 19 Jul 2013 10:46:48 +1000
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Peter Thatcher <pthatcher@google.com>, "<rtcweb@ietf.org>" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Fri, Jul 19, 2013 at 2:53 AM, Martin Thomson <martin.thomson@gmail.com> wrote: > On 18 July 2013 08:12, Peter Thatcher <pthatcher@google.com> wrote: >> I believe I began paying attention to the mailing lists after you sent out >> theses slides that you didn't present. I'm interested in seeing them, and >> while I could dig through archives to find them, if convenient, could you >> please give me a link to the slides? Thanks. > > It wasn't actually November, it was October, which made this harder to > find than I had expected. > > http://lists.w3.org/Archives/Public/public-webrtc/2012Oct/0148.html This captures exactly the kind of questions and concerns I had. Excellent work! However, I don't fully agree with the conclusion of the slide deck. I'd prefer we extended the constraints and other browser APIs that set the SDP parameters rather than (or: in preference to) fully specifying what SDP the browser has to support. I do like the ability to get the low-level access to mangle the SDP as a means of experimenting with new functionality or as a means to try and connect to devices that don't have a WebRTC API. But I see the full definition of the SDP parameters that browsers have to support as less important and potentially just a by product of creating the higher level APIs. What does it take for us to get focused on defining such an API that is independent of SDP for the JS developer, and for now requires browsers to do the mapping to SDP for them? Is the extension of the constraints that a JS dev can manipulate enough for this? Silvia.
Received on Friday, 19 July 2013 00:47:35 UTC