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

[Peter Thatcher <[e-mail]>]

Just in case it is missed elsewhere in the thread, I'll reply directly to
my own message.  It was pointed out to me that I made a mistake with my
addition.  The first line should have read:

61% "Good for simple Stuff"        39% "Bad for simple stuff"

Sorry about that.


On Wed, Jul 3, 2013 at 2:06 PM, Peter Thatcher <[e-mail]> wrote:

> After about a week of input, and feedback from 19 developers doing a wide
> range of things using the WebRTC API, we have some data about their opinion
> of the current API.
>
> *Short answer*:
>
> 61% "Good for simple Stuff"    49% "Bad for simple stuff"
>  6% "Good for advanced stuff"      94% "Bad for advanced stuff"
> 46% "Good/OK/tolerable for 1.0"    54% "Horrible/intolerable for 1.0"
>  7% "Good/OK/tolerable long-term"  93% "Need a better API long-term"
>
>
> In general the attitude is *"It's OK for simple stuff but bad for
> advanced stuff",  *and *"We can tolerate it for 1.0, but we need
> something better for 2.0".  *But the majority of the feedback was against
> it even for the 1.0, so the last one is a bit of a stretch.
>
>
> *Long Answer*:
>
> I had to interpret the results a little to fit into these buckets, so if
> you don't like the interpretation, you're more than welcome to interpret
> your own results from the raw data:
> https://docs.google.com/spreadsheet/ccc?key=0AuaKXw3SkHMSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=1
>
>
> There seem to be 4 or 5 different camps:
>
> Camp #1:  Doing very simple things, doesn't touch the SDP.  Everything is
> fine, except they might have things they want to control but can't.
>
> Camp #2:  Does somewhat more advanced things, touches the SDP a little,
> has pain, anticipates more pain, would like something better, but thinks
> this is OK for 1.0.
>
> Camp #3:  Is trying advanced things, is touching the SDP a lot, and really
> feels pain.  Wants something better, and might tolerate this API for 1.0,
> but not for long.
>
> Camp #4:  Doesn't want SDP or O/A in the API at all.  Has a very strong
> dislike for it.  Won't tolerate it, even for 1.0.  The IETF and W3C should
> be embarrassed for even suggesting such a terrible API.  It's better to go
> back to the drawing board (if you think those words are strong, go read the
> spreadsheet or mailing list!)
>
> Oh, and of course, for completeness, we should describe Camp #0, which
> didn't have any input in this feedback:
>
> Camp #0:  I've used SDP for years and I'm very comfortable with it.  Using
> SDP as the control surface really helps my use case, which is legacy
> interop.  Defining an API without SDP would be too much work, and probably
> fail.  Look at what happened with SDPng!  Supporting all these advanced use
> cases doesn't seem worth it.   If developers are doing that much advanced
> stuff, they can learn to munge SDP.  It isn't that bad.
>
> (By the way, I'm not a member of Camp #0, so I may be a little off in my
> description of it.  If any member of Camp #0 would like to adjust that
> description, please feel free).
>
>
>
>
> *Suggested Next Step: Figure out what is needed for WebRTC++*
> *
> *
> As Cullen recently pointed out, we need to get a list of things developers
> want to be able to control in a future version of the API which could
> hopefully make developers happier Whether that future API is 1.0, 2.0, or
> 1.1 is an orthogonal question, but let's call it WebRTC++ for now.
> Clearly, they want a way to control things without SDP, and perhaps without
> O/A at all.  But what do they want to control?  We need a good list.
>
> I suggest we reach out more closely to the developers, and use their input
> to create not only a list of things they want to do, but a WebRTC++ API
> that fulfills those needs without requiring SDP munging.  I think we can do
> this in parallel with the current  API work without detracting from it
> (from the current work, that is).    Certainly there is plenty of energy
> from people interested in working on it (WebRTC++, that is).  Such parallel
> work would not only better capture the needs of developers, but could also
> improve the WebRTC (not ++) API  by incorporating ideas from it.
>
> So far, such activity has been frowned on, perhaps out of fear that it's a
> threat to the current work.  But I think it can be done in a way that
> doesn't threaten anything, and even learns from and builds on the valuable
> input we are receiving from developers.  The alternative is to ask all
> these developers to wait an indefinite amount of time and munge SDP like
> crazy until then, and that seems like a rather poor answer.  Therefore, I
> would support an exploratory effort at a "WebRTC++ API".
>
>
>
>
>
>
>
>