Re: API design

     Sorry no. You can find the slides at 
http://lcsd05.cs.tamu.edu/slides/keynote.pdf but honestly you're missing 
99% of the content if you just read the slides. The real meat is in the 
video.

     Take me word for it, this is the best API design video I have come 
across in the past 10 years. It's worth the effort ;)

Gili

On 6/27/2013 6:37 PM, piranna@gmail.com wrote:
>
> Don't you have the content in readable format? My listening is not so 
> good... :-/
>
> El 28/06/2013 00:28, "Gili" <cowwoc@bbs.darktech.org 
> <mailto:cowwoc@bbs.darktech.org>> escribió:
>
>     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
>>
>