- From: Peter Thatcher <pthatcher@google.com>
- Date: Mon, 15 Jul 2013 07:11:51 -0700
- To: Jim Barnett <Jim.Barnett@genesyslab.com>
- Cc: 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: <CAJrXDUGQk7UGiASdMk3GNY2Gz0+3_o_uEOVJ37Da3s+BtAvg0A@mail.gmail.com>
I think you phrased it much better than I did. The tricky bit is knowing which API ideas are "in safe working room" and which aren't :). On Mon, Jul 15, 2013 at 7:09 AM, Jim Barnett <Jim.Barnett@genesyslab.com>wrote: > OK, I see your point. My sense of the consensus (which curiously > happens to coincide with my own opinion) is that there is room for work on > API extensions to facilitate SDP mangling as long as it doesn’t delay other > things or undo work that has already been done.**** > > ** ** > > **- **Jim**** > > ** ** > > *From:* Peter Thatcher [mailto:pthatcher@google.com] > *Sent:* Monday, July 15, 2013 10:04 AM > *To:* Jim Barnett > *Cc:* 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**** > > ** ** > > That's a question of whether #3 is right or not. While I think that's a > worthy discussion to have, I was just trying to summarize, and get > confirmation on whether that's the current feeling of the working groups > and its leaders. Whether it's right or not is a separate question. **** > > ** ** > > ** ** > > On Mon, Jul 15, 2013 at 6:56 AM, Jim Barnett <Jim.Barnett@genesyslab.com> > wrote:**** > > 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] > *Sent:* Monday, July 15, 2013 9:46 AM > *To:* Stefan Håkansson LK > *Cc:* 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**** > > **** > > **** > > **** > > On Mon, Jul 15, 2013 at 6:15 AM, Peter Thatcher <pthatcher@google.com> > wrote:**** > > **** > > **** > > On Sun, Jul 14, 2013 at 7:04 AM, Stefan Håkansson LK < > 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>> 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>>:**** > > > >> 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/PrioAPI.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>> > > > > > > > _______________________________________________ > > rtcweb mailing list > > rtcweb@ietf.org <mailto:rtcweb@ietf.org> > > https://www.ietf.org/mailman/listinfo/rtcweb > > > >**** > > **** > > **** > > ** ** >
Received on Monday, 15 July 2013 14:13:04 UTC