W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2012

Re: Poll for preferred API alternative

From: Tim Panton <thp@westhawk.co.uk>
Date: Fri, 31 Aug 2012 14:15:58 -0700
Cc: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-Id: <BE94E168-8421-4800-BDBD-6F16782B5A07@westhawk.co.uk>
To: Tommy Widenflycht (ᛏᚮᛘᛘᚤ) <tommyw@google.com>
I'd love to hear if the SDP that you generate has been able to interop (without-rewriting somewhere along the line) with _any_ endpoint other than 
another identical implementation.

My experience in phono is that we _always_ have to parse-fillet-rewrite the SDP in both directions to get chrome to interop with anything.
My fear is that the same will be true of interop between different browsers which will leave us with every app needing to have multiple 
rewiters for each possible browser type/version.


Tim.
 
On 30 Aug 2012, at 07:00, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote:

> 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
> 
> 
Received on Friday, 31 August 2012 21:17:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 31 August 2012 21:17:00 GMT