Re: Proposal: Different specifications for different target audiences

On 19 July 2013 11:13, Roman Shpount <roman@telurix.com> wrote:
> So, my approach to API design would be different:
>
> a. Determine the underlying functionality based on use cases. You never
> define API methods based on use cases, this is bad design. You define
> capabilities. These would be things like I should be able to send audio and
> video over DTLS-SRTP, data over SCTP over DTLS for data, etc
>
> b. Create the API that provides complete control of the underlying
> capabilities at the lowest possible level without sacrificing overall
> security or performance. You want to expose all the system capabilities as
> close to the bare metal as possible with only possible restrictions being
> security (no raw socket access from browser javascript) and performance (no
> javascript codecs, at least not yet). API should give access to all system
> functionality regardless of the use case which will require such access.
> There should be concrete security or performance reason to deny access to
> features. This API should also be testable and unambiguously predictable
> (which is much more important then extendable API), so no string blob or
> dictionary interfaces.
>
> c. For users with common use cases you create javascript libraries that
> implement them.

Sounds like exactly what we did with CU-RTC-Web.  Step c. sometimes
happens in the browser (we did that for ICE), and sometimes outside
(see JQuery).

Received on Friday, 19 July 2013 18:21:30 UTC