Core + Levels/Modules ? (Was: Aiding early implementations of the web audio API)

On 23/05/2012 00:46, Chris Wilson wrote:

> One question - "exposing the behaviour of built-in AudioNodes in a
> manner that authors of JavaScriptAudioNodes can harness" sounds like
> subclassing those nodes to me, which isn't the same thing as providing
> only lower-level libraries (like FFT) and asking developers to do the
> hook-up in JS nodes.  What's the desire here?  I think Robert and Jussi
> are suggesting not to have the native nodes; Colin seems to be saying
> "just make sure you can utilize the underlying bits in JSNode".  Is that
> appropriate?


Should we perhaps use the same model as CSS and split the web audio 
features as "Core" (AudioContext, AudioNode, AudioParam and the 
JavaScriptAudioNode Interface) and a number of levels or modules 
defining the higher level features?

This could at least help us in framing the debate: I'd like to see a 
list of "importance" and "implementation complexity" levels rather than 
the binary all-or-nothing we tend to fall back to.

And if it is architecturally sound, we could actually split the spec 
along those lines and make it easier and faster to produce standards and 
implementations.
-- 
Olivier