- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Sat, 11 Jun 2011 11:21:25 +1200
- To: Doug Schepers <schepers@w3.org>
- Cc: public-audio@w3.org, Francois Daoust <fd@w3.org>, Philippe Le Hegaret <plh@w3.org>, "Michael(tm) Smith" <mike@w3.org>, Dan Burnett <dburnett@voxeo.com>, Dominique Hazael-Massieux <dom@w3.org>, Paul Bakaus <pbakaus@zynga.com>, Tobie Langel <tobie@fb.com>
- Message-ID: <BANLkTims6wJQiL=frO_1a6jQvy3-exaqwA@mail.gmail.com>
On Sat, Jun 11, 2011 at 4:27 AM, Doug Schepers <schepers@w3.org> wrote: > Robert O'Callahan wrote (on 6/9/11 5:46 PM): > >> As a veteran of decade-long efforts to resolve conflicts between specs >> that never should have happened in the first place (SVG, CSS and HTML, >> I'm looking at you), I think it's worth taking time to make sure we >> don't have another Conway's law failure. >> > > I am with you there. As you know, I have always advocated for closer > integration of these technologies, from the failed effort in the Compound > Documents WG to the more successful FX Task Force. I don't think that this > is the problem here... there are plenty of people talking to one another, > and genuine open minds, but there is also a reasonable technical case for a > degree of separation. I have not yet heard any *technical* arguments for separation yet. I have only heard arguments that it's easier to organize the spec writing that way. Five years from now, when everything's specced and implemented, would authors be saying "I'm glad Streams and AudioNodes are different kinds of objects, that makes my life easier"? > The immediate demand for audio >> API will have to be (and is being) satisfied by libraries that abstract >> over browser differences, and that will remain true for quite some time >> no matter what the WG does. >> > > I can read this two ways (I don't know which way you meant it... maybe some > third way?): > > 1) "Script libraries will help build audience-appropriate abstraction > layers that make whatever the Audio WG does better fit the needs of that > particular audience"; or > > 2) "We are going to do our own audio API our way, and ignore what is being > done by the Audio WG or the other implementers." > I meant a third way: 3) The immediate demand for audio is being satisfied by libraries like XAudioJS that abstract over existing non-standard browser audio APIs. This is a temporary solution. Having divergent and competing APIs might seem like an evolutionary sound > "survival of the fittest" approach, > There are trade-offs. Sometimes it's worth having a competing spec; we didn't like WebSQLDatabase so we (with Microsoft) created WebIndexedDB. I'm less opposed to AudioNode than WebSQLDatabase, and I can see us supporting both AudioNode and a Streams-based API if we had to. We'd make AudioNodes and Streams map to the same kind of object internally. Rob -- "Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true." [Acts 17:11]
Received on Friday, 10 June 2011 23:21:54 UTC