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

Re: Simplifying specing/testing/implementation work

From: Marcus Geelnard <mage@opera.com>
Date: Sat, 21 Jul 2012 16:35:17 +0000
Message-ID: <20120721163517.zlkn39gpny7kswsg@staff.opera.com>
To: Chris Wilson <cwilso@google.com>
Cc: Raymond Toy <rtoy@google.com>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, public-audio@w3.org
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%

> 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  

Now, if it would come to the point where we have some browsers that  
implement "level 2", and some that don't (which I agree would be  
unfortunate - the goal must of course be equal functionality across  
browsers), we'd still have the possibility of supplying a JS shim that  
implements level 2 upon the core spec (I'd personally volunteer to  
implement it, if necessary), so that Web developers would have access  
to all the nodes, regardless of browser. In my experience, people that  
develop fairly complex software (such as games) are not afraid of  
using 3rd party libraries (rather the opposite, actually), so this  
should not really be a problem.


Received on Saturday, 21 July 2012 16:35:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:11 UTC