- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Thu, 30 Aug 2012 02:29:58 -0400
- To: public-webrtc@w3.org
On 8/29/2012 7:51 PM, Ted Hardie wrote: > On Wed, Aug 29, 2012 at 5:30 AM, Stefan Hakansson LK wrote: > >> 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. >> > > I strongly support continuing to build on the PeerConnection object approach. [Changing title to avoid causing the chairs extra work.] > I think the games and other applications which have been demonstrated > so far are a strong indication that even Hackathon-style events can > produce fun user experiences with this approach. From the beginning, > I've been concerned that exposing only an API that was low level would > discourage Javascript application writers from exploring the space. > While the "twenty lines to build chat roulette" mantra might have been > too restrictive, I think that level of thinking should be in our minds > even if we are relying on common libraries. A much-discussed issue when things like this were last brought up was that external libraries to provide higher-level functionality work, but have a severe problem with maintainability. In particular, application authors tend to import once, then basically never update. (Updating is work, app is no longer maintained or no update is planned at a similar time, APIs change, retesting is needed, inertia, not knowing updates are available, etc.) You can see this pattern in play with frameworks like jQuery and others. The extra downside of that here is that these would be critical to interoperation, and also bugfixes to complex beasts like ICE state machines are likely. Failure to keep these up-to-date would lead to increasing incompatibility and/or fragility, and it would also lead to quick stagnation due to the problem of getting applications to update. There may be downsides, but the update pattern of browsers is typically much faster and more universally deployed. > I'm also concerned with another reset at this point. The ROAP to JSEP > switch worried me from a timing perspective; this would be at least > the equivalent loss of time and maybe much more. I strongly agree with this. I thought we were too far down the road already at that point for it to avoid setting us back, and it probably did delay us (if for no other reason than the hours of critical people's time developing, reading, critiquing and revising JSEP). I do think there are some aspects of the proposal that can and should be incorporated into the current effort, but I think a wholesale switch would dramatically set us back. I'll address some of those details and technical debt in another post. > I do not see benefits that correspond to the costs of a reset at this > point, speaking personally, I think the group should move forward on > the current course. -- Randell Jesup randell-ietf@jesup.org
Received on Thursday, 30 August 2012 06:32:07 UTC