- From: <piranna@gmail.com>
- Date: Mon, 15 Jul 2013 16:00:12 +0200
- To: Jim Barnett <Jim.Barnett@genesyslab.com>
- Cc: Peter Thatcher <pthatcher@google.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>
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>: > 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 >> >> > > > > -- "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:01:09 UTC