Re: Poll for preferred API alternative

I support alternative 1.

Don't leave to much complexity in the hands of a the JS coders. And we 
don't need any more delays.

Regards
frodek

Den 29.08.2012 14:30, skrev Stefan Hakansson LK:
> 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 07:31:53 UTC