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