W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: Proposal: Different specifications for different target audiences

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 19 Jul 2013 11:21:03 -0700
Message-ID: <CABkgnnUY_=qAx75cgLTRo8F1ow36Qd5R1SDdOZWU-M+4ti7vXw@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: cowwoc <cowwoc@bbs.darktech.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC