Re: Poll for preferred API alternative

My definite vote is on alternative 1. Alternative 2 completely misses the
user base, a normal web developer without expertise in video conferencing
will have a very hard time getting something working. We need to provide a
pretty big, but high-quality and light, showel because it is a big hole
that has to be dug.

I do see the value in having a low-level api but now is not the right time
to discuss one.

I might be partial since I am implementing PeerConnection right now in
WebKit but I am also a big fan of the WebRTC concept and would be very sad
if the specification completely misses its target. The PeerConnection is
not perfect and I definitely don't agree with everything but, and it's a
big but, it does its job well.

/Tommy

On Wed, Aug 29, 2012 at 2:30 PM, 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
>
>


-- 
Tommy Widenflycht | Senior Software Engineer | tommyw@google.com | +46
734162531
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880