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: Wed, 01 Aug 2012 06:19:31 +0000
Message-ID: <20120801061931.2u517e62u34gc08k@staff.opera.com>
To: Tony Ross <tross@microsoft.com>
Cc: Chris Wilson <cwilso@google.com>, Raymond Toy <rtoy@google.com>, Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, "public-audio@w3.org" <public-audio@w3.org>
Citerar Tony Ross <tross@microsoft.com>:

>> From: Marcus Geelnard [mailto:mage@opera.com]
>> 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.

Yes, I think the key point here is to identify and prioritize the work  
on the "core". Splitting the spec into levels would just be a very  
distinct way of doing that.

> 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.

Agreed. I personally think that the "architecture" part (context,  
graph routing, automation, etc) should be in the core feature set,  
plus a minimal set of nodes that make it possible to implement the  
majority of sound processing nodes in a straight forward manner  
(though possibly with less performance than with specialized nodes).  
That way we would be quite sure that the API is future proof and  
easily extensible.

Received on Wednesday, 1 August 2012 06:20:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:01 UTC