Re: Proposal: Different specifications for different target audiences

+1
El 19/07/2013 18:19, "cowwoc" <cowwoc@bbs.darktech.org> escribió:

>
>     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:
>     - One for Browser Vendors.
>        - One for Integrators.
>       - One for Web Developers.
>
>     What do you think?
>
> Gili
>