Re: Poll for preferred API alternative

#1.  However, this will require a) faster agreement on SDP behavior in implementations than happened with SIP devices, and b) simpler ways to manipulate SDP in the mean time.  Objectifying SDP in the API might help with this.

-- dan

On Aug 29, 2012, at 8:30 AM, Stefan Hakansson LK 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
>

Received on Friday, 7 September 2012 13:22:10 UTC