Re: Proposal: Different specifications for different target audiences

Hi Matthew,

     I'll bite :)

     If you read down to the bottom you'll find I wrote: "The APIs 
should be driven by use-cases and developed from the top-down." Put 
another way, that means that the signaling layer is subservient to the 
layers above it.

     Which part of that implies that the browsers are free to "conspire 
with each other to do something other than what you asked for in the 
Javascript API"?

Thanks,
Gili

On 19/07/2013 2:39 PM, Matthew Kaufman (SKYPE) wrote:
>
> Doesn't solve the basic problem.
>
> You don't want **any** specification that describes a "signaling 
> layer" over which the browsers conspire with each other to do 
> something other than what you asked for in the JavaScript API.
>
> Matthew Kaufman
>
> *From:*cowwoc [mailto:cowwoc@bbs.darktech.org]
> *Sent:* Friday, July 19, 2013 9:17 AM
> *To:* public-webrtc@w3.org
> *Subject:* Proposal: Different specifications for different target 
> audiences
>
>
>     The WebRTC specification has 3 target audiences:
>
>  1. Browser vendors
>  2. Integrators
>  3. Application Developers
>
>     Currently, we have lump them into a single category and put out a 
> single specification document and API for all three. I believe this is 
> a huge mistake and the cause of most of our problems. It is reasonable 
> that these people cannot come to an agreement because they have 
> different (perfectly reasonable!) requirements.
>
>     I propose doing the following:
>
>  1. Browser vendors publish a signaling layer specification.
>  2. Integrators publish a low-level (object-oriented) API.
>  3. Application Developers publish a high-level (object-oriented) API.
>  4. Browser vendors implement the low-level API on top of the
>     signaling layer.
>  5. Application Developers implement the  high-level API on top of the
>     low-level API.
>
>     Benefits:
>
>   * The browser vendor implements the low-level API once and both
>     Integrators and Application Developers reuse this code (as opposed
>     to everyone digging their fingers into the signaling layer as
>     we're currently forced to for some common use-cases).
>   * Integrators get the low-level API they need to ensure
>     interoperability.
>   * Application Developers get a high-level API.
>   * Both Integrators and Application Developers are now protected from
>     changes to the signaling layer. The underlying signaling protocol
>     may change without breaking their code.
>   * On the flip side, browser vendors are free to change the
>     underlying signaling protocol with much less backwards
>     compatibility baggage.
>   * Application Developers who want to explore experimental features
>     or advanced use-cases can use the low-level API as needed.
>
>     Process:
>
>   * The APIs should be driven by use-cases and developed from the
>     top-down.
>   * Meaning, Web Developer use-cases should drive the high-level API
>     which, in turn, will drive changes to the low-level API and
>     signaling layer.
>   * Similarly, Integrator use-cases should drive the low-level API
>     which, in turn, will drive changes to the signaling layer.
>   * Ideally, implementation details should never travel upwards.
>     Meaning, signaling layer requirements should not leak up to the
>     high-level API.
>   * We publish separate documents for the different target audiences:
>
>       o One for Browser Vendors.
>       o One for Integrators.
>       o One for Web Developers.
>
>     What do you think?
>
> Gili
>