Re: Proposal: Different specifications for different target audiences

On Sun, Jul 21, 2013 at 8:40 PM, Eric Rescorla <ekr@rtfm.com> wrote:

>
>
>
> Generally, we've talked about three kinds of APIs:
>
> High-Level: Effectively SIP in the browser
> Mid-Level: What we have now
> Low-Level: Something in the vein of CU-RTC-Web
>
> We've seen proposals for all of these and I think there was
> rough consensus to do a mid-level API and in particular
> JSEP (and incidentally not to do a low-level API). To my
> knowledge, there has never been any kind of consensus
> call not to do a Mid-Level API, and it would represent
> a major shift in WG direction.
>
>
I would see API more of the continuum then exact division between the three
categories. Even current API has low level and mid level features. In this
sense, API callbacks for trickle ICE more likely to belong to lower level
API then to what you would call mid-level. API methods proposed in noplan
draft also add lower level methods to add and remove media streams. If we
wanted to maintain the current abstraction level, we should have waited for
SDP update mechanism to be defined for trickle ICE and media stream updates
and exposed them as API methods that take appropriate SDP blobs. I am in no
way advocating this. I think decision to use API methods which takes values
directly for trickle ICE was the right decision. All I am looking for is
not taking the current API to the level as low as CU-RTC-Web, but to
logically expose all the current functionality at the same level as trickle
ICE callbacks and noplan media stream methods. So, in some sense, this will
bring current API to the same consistent level of abstraction and fix yet
another design shortcut.
_____________
Roman Shpount