Re: API design

     I wish I could unsend that last email :)

     Now that I look at it, the slides are pretty darn good. I still 
recommend watching the video, as you will get a much better 
understanding than just reading the slides alone.

Gili

On 6/27/2013 6:44 PM, Gili wrote:
>
>     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
>>>
>>
>