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.

/Marcus
Received on Wednesday, 1 August 2012 06:20:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 1 August 2012 06:20:07 GMT