W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

RE: Simplifying specing/testing/implementation work

From: Tony Ross <tross@microsoft.com>
Date: Wed, 1 Aug 2012 00:04:07 +0000
To: Marcus Geelnard <mage@opera.com>, Chris Wilson <cwilso@google.com>
CC: Raymond Toy <rtoy@google.com>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, "public-audio@w3.org" <public-audio@w3.org>
Message-ID: <C5EA8F3A4B854B4386C8C7AEDA1A90501A67FB68@TK5EX14MBXC221.redmond.corp.microsoft.com>
> From: Marcus Geelnard [mailto:mage@opera.com]
> 
> Citerar Chris Wilson <cwilso@google.com>:
> 
> > I'd like to request that we not plan any grand changes here until
> > Chris is back from vacation (end of the month).
> 
> Agree 100%

(Revisiting this thread now that Chris Rogers is back)

> > My opinion- in short, I oppose the idea of having a "core spec" as
> > captured above.  I think it will simply become a way for implementers
> > to skip large parts of the API, while causing confusion and
> > compatibility problems for developers using the API.
> 
> Just to make things clear: That was never the intention of my suggestion.
> My key concern is mainly how to speed up the process of getting a common,
> robust, powerful, future proof audio API available in as many browsers
> as possible.
> 
> I think that splitting the spec into two layers would make it easier to
> focus on what's really important to get right in the spec (i.e. the
> core), and getting that part ironed out and testable ASAP. That way we
> can hopefully lift the "experimental" tag from at least the most
> important parts of the API, while continuing to stabilize the next level.

I definitely think there's value in identifying which features we think are most important for developers so we can ensure these stabilize sooner. I'm not advocating where that line should be (maybe it's even most of the current spec), but we certainly should have some form of consensus on it, if for nothing other than to aid in discussions around potential additions to the standard. 

To start, I do think the flexibility provided by JavaScriptAudioNode makes it an important part of that core feature set, regardless of what other nodes/capabilities we decide to include. Also anywhere we do draw a line we should ensure that the presence or absence of the next level of support can be easily identified via feature detection to reduce the confusion/burden placed on developers.

- Tony
Received on Wednesday, 1 August 2012 00:04:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 August 2012 00:04:42 GMT