- From: Peter Thatcher <pthatcher@google.com>
- Date: Mon, 15 Jul 2013 07:09:18 -0700
- To: Jim Barnett <Jim.Barnett@genesyslab.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: <CAJrXDUFgi0ykQ_mX+jRjeK-VXphga53vno7iVLGFJ_rwZ2_+=g@mail.gmail.com>
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>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] > 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 > 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>: > > 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/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>> > >> > > >> > >> _______________________________________________ > >> 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:10:27 UTC