Re: Poll for preferred API alternative

On 2012-08-29 14:30, Stefan Hakansson LK 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.

I support alternative 1.

Perhaps the low level approach gives us more reusable components, but I 
don't think it's worth the added complexity for JavaScript developers. I 
have no doubt that component reuse is something that browser developers 
will pursue even without having it explicitly in the standard.

/Adam

Received on Thursday, 30 August 2012 13:06:30 UTC