Re: Poll for preferred API alternative

I agree that current approach (with PeerConnection) is reasonable and it's
better to move forward with it. The problem with flexibility of CU-WebRTC
design is that it will make everything more complicated for usual web
developers. Even with the current approach they need to have some real
skills, but if we go in the flexibility direction we will end up with
unreasonable complexity (it always happens this way). You can always use
gateways for interconnection with some specific software/hardware and
current architecture doesn't limit that anyhow.

P.S. impossible to create the standard everybody in the world will be
happy with.

Best Regards,
Alexey Aylarov

8/30/12 3:51 AM ïîëüçîâàòåëü "Ted Hardie" <ted.ietf@gmail.com> íàïèñàë:

>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.
>
>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.
>
>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 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.
>
>regards,
>
>Ted Hardie
>

Received on Thursday, 30 August 2012 05:46:09 UTC