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

[Peter Thatcher <[e-mail]>]

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".