Re: Poll for preferred API alternative

I have reviewed the CU-RTCWEB proposal extensively, and have considered
every individual point mentioned in the "delta" slide from the telco
presentation. I believe that the key differences are primarily around the
way the developer interacts with the API, and any desirable features from
this CU-RTCWEB proposal could be cleanly incorporated into the current
PeerConnection design.

In addition, the PeerConnection design has proven to be readily
understandable by developers, and we have seen realtime applications
created with a few dozen lines of WebRTC-related code. However, as
indicated in the CU-RTCWEB proposal, this ability to easily create
applications is considered a non-goal in CU-RTCWEB. When combined with the
developer confusion and loss of momentum that would come along with a WG
reset, I think continuing with the current design will lead to wider WebRTC
adoption.

As a result, I prefer option 1.




On Wed, Aug 29, 2012 at 5:30 AM, Stefan Hakansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> The discussions of Aug 28 showed that there are people with differing
> opinions on the structure of the API this WG should design.
>
> Most of the work in front of this group currently is dependent on a basic
> decision between those two approaches - the issues to be resolved (for
> example congestion control and RTP stream mapping) are in many cases
> present in both proposals, but the API specifications that need to be
> developed look a lot different.
>
>
> It is not efficient use of the group’s time to work out detailed,
> implementable proposals that then are thrown away because of a later
> decision - nor is it a working environment conducive to inspiring
> volunteers.
>
> The two alternatives, as the chairs see them, are the following:
>
> 1) Continue with a design based on the PeerConnection object, using SDP as
> part of the API, roughly in the style of the current API description.
> 2) Remove the PeerConnection object and all use of SDP from the API, and
> pursue an API roughly in the style of Microsoft’s CU-WebRTC proposal.
>
> In order to make this call, we’re calling for the WG participants to make
> their opinion known, by indicating one of three alternative opinions:
>
> 1) The group should continue with a design based on the PeerConnection
> object, using SDP as part of the API.
> 2) The group should remove the PeerConnection and all use of SDP from the
> API, and pursue a design based on the CU-WebRTC proposal.
> 3) This participant does not have enough information to state an opinion
> at this time.
>
> The chairs will make the result of the opinion tally public after the end
> date.
>
> If this call results in a clear preponderance for one of the alternatives,
> the WG chairs will take that as direction - if the last alternative has a
> clear preponderance, the WG chairs will direct the WG pursue further
> discussion of this topic only, putting all other work on hold until this is
> resolved; in the two other cases, the chairs will direct the WG pursue the
> chosen design option, and leave the other to others to follow up if they
> wish, but not drive it further in the WG.
>
> This is not a vote - it is a tallying of opinions. If a preponderance of
> preference is clear, the chairs will ask the WG if it agrees that a
> consensus exists to proceed based on that preference.
>
> Please state your opinion before Friday, Sept 7, and communicate this to
> the chairs. Mail to the list is an acceptable means of communicating your
> opinion.
>
> Stefan for the chairs
>
>