- From: Peter Thatcher <pthatcher@google.com>
- Date: Mon, 15 Jul 2013 06:15:50 -0700
- To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Cc: Iñaki Baz Castillo <ibc@aliax.net>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAJrXDUGSS=m93MEpOm01c1BkspLrG+QhO73wmzH=+mPOfJnQnQ@mail.gmail.com>
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? > > > [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 13:16:59 UTC