External libraries

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