RE: Proposal: Different specifications for different target audiences

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:

     *   One for Browser Vendors.
     *   One for Integrators.
     *   One for Web Developers.
    What do you think?

Gili