- From: Marcus Geelnard <mage@opera.com>
- Date: Sat, 21 Jul 2012 16:35:17 +0000
- 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 level. 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. Regards, Marcus
Received on Saturday, 21 July 2012 16:35:52 UTC