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

Re: API design

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Fri, 28 Jun 2013 19:19:04 -0400
Message-ID: <51CE19E8.6010805@bbs.darktech.org>
To: public-webrtc@w3.org

     Using the slides found at 
http://lcsd05.cs.tamu.edu/slides/keynote.pdf as reference, I'd like to 
make the following proposal:

  * The editors should publish a design document.
  * Slide 8: This document should list all use-cases we plan to address.
  * Slide 9: Each use-case should be accompanied by a code-sniplet
    (example code, unit test) showing how it is addressed by the API.
  * Slide 10: WebRTC is an Service Provider Interface (SPI). We need at
    least 3 implementations in order to publish 1.0. Chrome and Firefox
    are two. Who will be the third?

     The slides contains many other points, but let's start with the above.


On 27/06/2013 6:26 PM, Gili wrote:
> Hi,
>     I'd like to discuss the issue that is closest to my heart, which 
> is designing WebRTC for normal web developers, not telecom experts.
>     I'll fire the opening salvo by recommending you watch this video: 
> http://www.infoq.com/presentations/effective-api-design
>     As I mention to Cullen, this talk has shaped my professional 
> career. Pay special attention to "Characteristics of a Good API", 
> especially his explanation of the last bullet point :)
> Thank you,
> Gili
> On 6/27/2013 10:19 AM, Gili wrote:
>> Hi,
>>     (If you'd like to respond to individual points, please start a 
>> separate topic)
>>     I'd like to start a discussion of issues that came up during the 
>> WebRTC World conference (in sessions and while speaking with Dan 
>> Burnett and Cullen Jennings):
>>  1. Ending the VP8/H264 war: A proposal was made to mandate a
>>     patent-unencumbered codec (whose patents have expired or are not
>>     enforced) as mandatory and optionally upgrade to other codecs
>>     such as VP8 or H264 depending on peer capabilities and personal
>>     preferences. VP8 guys can use VP8. H264 guys can use H264. And if
>>     the two camps need to chat with each other they can fall back on
>>     H263. This gives you the flexibility of arbitrary codecs without
>>     the need to do transcoding.
>>  2. The WebRTC API needs to focus on normal web developers, not not
>>     telecom experts: The conversation on this mailing list is unduly
>>     skewed in favor of telecom experts which make up a tiny minority
>>     of WebRTC end-users. We need to find a way to collect feedback
>>     from the Javascript community at large in order to ensure that
>>     the API facilitates their use-cases. The proliferation of WebRTC
>>     SDKs for end-users (the conference was full of them) is a strong
>>     indication that there is a gap to be filled.
>>  3. Implementers vs End-users: The specification document has two
>>     target audiences, implementers and end-users. We need to provide
>>     implementers with a lot of low-level detail but make as little
>>     guarantees as possible to end-users to leave the door open to
>>     future change (without breaking backwards compatibility). We
>>     discussed explicitly marking-up sections of the specification
>>     "for implementers" or "for end-users" or separating the
>>     specification into separate documents. We need to make it clear,
>>     for example, that the specification does not make any guarantees
>>     regarding the contents of the SDP token. Implementers need a
>>     detailed breakdown in order to implement WebRTC 1.0 but end-users
>>     may not rely on these details because the token might not even be
>>     SDP in future versions.
>>  4. SDP: Users should interact with the Constraints API instead of
>>     SDP. It is true that there are some use-cases that are not yet
>>     covered by this API (forcing you to manipulate the SDP directly)
>>     but the plan is to address all these use-cases by 1.0 so users
>>     never have to interact with SDP directly. "If your use-case is
>>     not covered by the Constraints API, please tell us right away!"
>>  5. Offer/Accept: There are plans to enable peers to query each
>>     other's capabilities and change constraints (and as a result the
>>     offer/answer) in mid-call.
>>  6. Troubleshooting WebRTC: We need to do a better job diagnosing
>>     WebRTC problems. We need a user-friendly application (run by
>>     non-developers!) for quickly debugging network and microphone
>>     problems (Skype does this), and allow users to drill down into
>>     more detail if necessary. We also need programmatic access to
>>     this API so WebRTC applications can detect problems at runtime
>>     and decide (for example) to refund users who paid for a call that
>>     was subsequently aborted due to network problems.
>>  7. Use-cases, use-cases, use-cases: "Tell us what is wrong, not how
>>     to fix it". You are a lot more likely to get traction for your
>>     problems if you help us understand your use-cases then trying to
>>     argue for change for its own sake. On the flip side for
>>     specification editors, I encourage you to actively engage posters
>>     (ask for these use-cases) instead of ignoring discussion threads ;)
>>     I encourage other people who attended the conference to 
>> contribute their own discussion points.
>>     (If you'd like to respond to individual points, please start a 
>> separate topic)
>> Thank you,
>> Gili
Received on Friday, 28 June 2013 23:19:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:44 UTC