W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface

From: Peter Thatcher <pthatcher@google.com>
Date: Mon, 15 Jul 2013 07:09:18 -0700
Message-ID: <CAJrXDUFgi0ykQ_mX+jRjeK-VXphga53vno7iVLGFJ_rwZ2_+=g@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:34 UTC