- From: Jim Barnett <Jim.Barnett@genesyslab.com>
- Date: Mon, 15 Jul 2013 14:10:44 +0000
- To: Peter Thatcher <pthatcher@google.com>
- CC: "piranna@gmail.com" <piranna@gmail.com>, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, Iñaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <57A15FAF9E58F841B2B1651FFE16D28105A2BB@GENSJZMBX01.msg.int.genesyslab.com>
OK, fair enough. - Jim From: Peter Thatcher [mailto:pthatcher@google.com] Sent: Monday, July 15, 2013 10:09 AM To: Jim Barnett Cc: piranna@gmail.com; Stefan Håkansson LK; Iñaki Baz Castillo; public-webrtc@w3.org Subject: Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface I don't mean to be rude by saying "get another thread", but... could you guys discuss this on a separate thread? I was hoping this thread could stick to just getting feedback on what the feeling of the working groups is and what would be meaningful to discuss. Personally, I don't want to discuss alternative API approaches too much unless there is interested in it and it's not viewed as a threat to the current API. You can, of course, but would you please do it on a separate thread? On Mon, Jul 15, 2013 at 7:06 AM, Jim Barnett <Jim.Barnett@genesyslab.com<mailto:Jim.Barnett@genesyslab.com>> wrote: We could add an object-oriented API that defined a javascript structure representing the SDP. Developers could modify the structure using JavaScript, rather than having to parse it themselves. Given such a JS structure, it would be easy to serialize it as JSON, so developers wouldn't need to touch the SDP directly. But they would still have the option to do so, if they wanted to do something that the API didn't cover (and it would be up to us to decide how much the API covered.) - Jim -----Original Message----- From: piranna@gmail.com<mailto:piranna@gmail.com> [mailto:piranna@gmail.com<mailto:piranna@gmail.com>] Sent: Monday, July 15, 2013 10:00 AM To: Jim Barnett Cc: Peter Thatcher; Stefan Håkansson LK; Iñaki Baz Castillo; public-webrtc@w3.org<mailto:public-webrtc@w3.org> Subject: Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface Are you proposing to ship a high- and low-level capable API, one accesible with RTCSDPType and the other mangling directly with the SDP string? 2013/7/15 Jim Barnett <Jim.Barnett@genesyslab.com<mailto:Jim.Barnett@genesyslab.com>>: > I'm not sure even the revised 3) is correct. There is certainly a > strong focus on getting version 1 done, and on not un-doing work that > has already been done. However a carefully designed API sitting on > top of SDP would be largely independent of the rest of the API and would not necessarily delay > things. If we just elaborate RTCSDPType, only section 4.7 is affected. > If it got done in time, it would be part of version 1. If it didn't, > it could end up in a later version. > > > > - Jim > > > > From: Peter Thatcher [mailto:pthatcher@google.com<mailto:pthatcher@google.com>] > Sent: Monday, July 15, 2013 9:46 AM > To: Stefan Håkansson LK > Cc: Iñaki Baz Castillo; public-webrtc@w3.org<mailto:public-webrtc@w3.org> > Subject: Re: [rtcweb] Summary of Application Developers' opinions of > the current WebRTC API and SDP as a control surface > > > > > > > > On Mon, Jul 15, 2013 at 6:15 AM, Peter Thatcher <pthatcher@google.com<mailto:pthatcher@google.com>> > wrote: > > > > > > On Sun, Jul 14, 2013 at 7:04 AM, Stefan Håkansson LK > <stefan.lk.hakansson@ericsson.com<mailto:stefan.lk.hakansson@ericsson.com>> wrote: > > On 7/12/13 7:32 PM, Peter Thatcher wrote: >> >> >> > >> On Tue, Jul 9, 2013 at 4:26 AM, Stefan Håkansson LK >> <stefan.lk.hakansson@ericsson.com<mailto:stefan.lk.hakansson@ericsson.com> > >> <mailto:stefan.lk.hakansson@ericsson.com<mailto:stefan.lk.hakansson@ericsson.com>>> wrote: >> >> On 2013-07-09 12:18, Iñaki Baz Castillo wrote: >> > 2013/7/9 Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com<mailto:stefan.lk.hakansson@ericsson.com> > >> <mailto:stefan.lk.hakansson@ericsson.com<mailto:stefan.lk.hakansson@ericsson.com>>>: > >> >> I want to be very clear and careful on what I say. So I am >> repeating: >> >> >> >> * My comment that I think Eric is right in that there is >> consensus on >> >> providing APIs that allow most use-cases to be met without SDP >> mangling >> >> is meant only in that context: SDP O/A is kept (and >> PeerConnection more >> >> or less as is and so on). >> > >> > Hi Stefan, >> > >> > You insist that "there is consensus on keeping SDP O/A but >> providing a >> > better API". >> >> I must be expressing myself quite badly, because the message seems not >> to get through. >> >> * I think we have consensus on adding API that allows most >> use-cases to >> be met without SDP mangling (given that SDP O/A is kept >> naturally) >> >> * We discussed last year an alternative API that did not use SDP >> at all >> (and did not use PeerConnection). The decision at that time was to >> continue developing the API based on PeerConnection and SDP O/A. >> >> Have not stated anything more than that. >> >> >> Thank you for clarifying, Stefan. It's often very difficult for >> those of us who weren't there to understand what was consensus, and >> what wasn't, and what was decided and what was decided and what >> wasn't. It seems that if you ask 10 people, you get 10 different answers. >> >> >> In other words, it's hard to see much consensus on what we have >> consensus on. >> >> >> So thank you for your clarifications. It's probably not a very fun job >> for you :). Along with that, I have two more questions for you: >> >> >> 1. You said we have consensus on adding API that allows most >> use-cases to be met without SDP mangling. Since that point in time >> has there been in any progress in adding such APIs? Can you give me >> a rough feel for how much time has passed, how many proposals have >> been made, how many have been accepted, and how many have been >> implemented? I think it's great that we'll do this "someday", but >> I'd like to get a feel for how far away "someday" is. Thanks in advance. > > As I said earlier, there has been no consensus calls or anything, it > is just my feeling that we have consensus for this (and in fact the > chairs mention it in the "Poll result and next steps" mail [1]) - so > it is difficult to say how much time has passed. > > Off the top of my head I know of two proposals to add API surface for > this purpose, [2] and [3]. In addition, I know that you as well as > Justin has proposed to make the RTCSessionDescription object more > advanced, with methods to change certain things. > > > > I had an idea for making an abstract SessionDescription that could be > manipulated via dictionary properties rather than SDP text mangling. > But I never proposed it on the mailing list. I've been told that it > would be too disruptive to the working groups, so we shouldn't talk about it. > > > > Plus, while I think it would be a huge improvement, I'm not convinced > that it was good enough. Since then, we've come up with better ideas > that would make an even better API, but we haven't proposed them. > I've been told that it would be too disruptive to the working groups, > so we shouldn't talk about them. I proposed some ideas with the > NoPlan JS API, but apparently that was too much for the working groups > to handle, so I haven't dared to propose any more ideas. > > > > > Maybe others recall other proposals made? > > To be fair, I think it is more recently this need has become more > apparent. And, most of the effort has been on driving the "Media > Capture and Streams" document towards a LC - the "WebRTC 1.0" document > has to some extent been waiting for decisions and developments in the IETF. > > > > Is there interest in such ideas? I'd be more than willing to propose > things, but I have mostly refrained because so many people fear that > even talking about a different API would be too disruptive to the work > on the current API. If there is interest in discussion that would not > be too disruptive, please let me know, because I'm interested :). > > > > >> >> 2. You said we have consensus against an alternative API. Was that >> consensus against any additions to the API that would allow JS to >> bypass SDP, or was that a consensus against just that particular >> alternative API? I'd like to get a feel for how many people voted >> for "no; let's not go down that specific road" vs. "no; we cannot go on any road but >> this one". I think there's a big difference between the two. Thanks >> again in advance. > > In 2012 the CU-rtcweb proposal was brought to the WebRTC WG - while > the WG had for quite some time been working on an API based on > PeerConnection and the use of SDP. In order to be able to focus the > work the chairs arranged a poll, basically with the options to either > stay with PeerConnection and SDP, or switch to an API based on CU-rtcweb. > > The result ([1]) was that we should continue developing an API based > on PeerConnection and SDP. > > Additions to the PeerConnection API was not discussed at the time. > > > > I've read a lot of email that talk what the working groups have > consensus on in regards to the overall API, but I can only really nail > down a couple of concrete things (everything else seems unclear): > > > > 1. A year or so ago, almost everyone was against CU-RTCWEB. > > > > 2. Since then, few, if any proposals to change or add to the core of > the API have been proposed. None have made any progress. > (Specifically, I mean things that would allow JS control without doing > SDP mangling) > > > > 3. There's a very, very strong push by working group leaders to stay > focused on shipping the current API and not change or add anything major. > Any discussion of any API changes or additions that would allow a JS > app to do signaling without SDP is strongly frowned upon, because it would threaten > the progress on the existing API. It's even frowned upon to discuss with > web developers what their use cases and pains are, since their > feedback might threaten progress. > > > > > > Is that an accurate summary? > > > > > > Responding to my own comment here: I meant #1 and #2 to be the main summary > I was trying to get a reply on, not #3. I kind of threw #3 in as an > afterthought. And for #3, I meant mostly to focus on the part about > "we're staying focused on the current API; don't get distracted by > other stuff (yet)". The "what is frowned upon" was probably a bit to > negative on my part to mention, and wasn't what I really wanted to > focus on. Sorry about that. Please consider it removed for further discussion, and try to just > focus on the first parts. Or if that's not good enough, please accept > this modified #3: > > > > 3. There's a strong focus of working group leaders on shipping the > current API. They'd prefer any discussion of any API changes or > additions (such as that would allow a JS app to do signaling without SDP) to be saved until > after the current API is shipped. Too much discussion right now could > threaten the progress made so far, so we should save it for later. > > > > > > I hope that's better. > > > > > > > > > > > > > > [1] > http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0098.html > [2] > http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0025.html > [3] > http://lists.w3.org/Archives/Public/public-webrtc/2013Jan/att-0005/Pri > oAPI.pdf [4] > http://lists.w3.org/Archives/Public/public-webrtc/2012Aug/0211.html > > >> >> >> By the way, Ted asked us to move discussions about the API to >> public-webrtc, so should we do that now? >> >> >> >> Stefan >> >> > Given current discussions IMHO it is clear there is not >> > such a consensus (not at all). Or may be you are just talking about >> > two years ago in some IETF meeting (if so I'm sorry). >> > >> > Please review the results in >> > >> >> https://docs.google.com/a/aliax.net/spreadsheet/ccc?key=0AuaKXw3SkHMSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=1 >> > >> > Bad for advanced stuff: 94% >> > OK for 1.0: 40% >> > >> > IMHO such a result indicates all but "let's keep SDP O/A and >> improve a >> > bit the API" (I mean now, in July 2013). >> > >> > >> > Best regards. >> > >> > >> > >> > -- >> > Iñaki Baz Castillo > >> > <ibc@aliax.net<mailto:ibc@aliax.net> <mailto:ibc@aliax.net<mailto:ibc@aliax.net>>> >> > >> >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org<mailto:rtcweb@ietf.org> <mailto:rtcweb@ietf.org<mailto:rtcweb@ietf.org>> >> https://www.ietf.org/mailman/listinfo/rtcweb >> >> > > > > -- "Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." - Linus Tordvals, creador del sistema operativo Linux
Received on Monday, 15 July 2013 14:11:09 UTC