- From: Olivier Thereaux <Olivier.Thereaux@bbc.co.uk>
- Date: Tue, 18 Jun 2013 13:54:40 +0000
- To: "public-audio@w3.org" <public-audio@w3.org>
On 18/06/2013 04:09, "Robert O'Callahan" <robert@ocallahan.org> wrote: > >If we require Web developers to make major modifications to work with the >unprefixed AudioContext, then for many of them it becomes easier to just >tell their users to use Chrome. This sounds fairly drastic. Our recent sample (of one, thus obviously not statistically relevant, but interesting anyway) of developers seems to be happy updating their code along with the development of our spec and the introduction of new implementations. While Mozilla may be worried that app/sites developers will tell users to "just use Chrome" rather than fix a handful of lines of their code, I believe developers may be equally worried about bad publicity and lost users if they are pointed at for sticking to prefixed code and deprecated interfaces, or simply because their old code doesn't work everywhere when everyone else's (especially later adopters') does. I am hopeful that there is a decent compromise somewhere. If I can try and summarise some of the mitigating ideas which have been introduced in this thread so far: * Collect and maintain a list of all the significant pieces of documentation of the API * Update HTML5rocks and other documentation which we control directly * Get our community to help us ask implementers and writers to update their examples * Communicate positively about upcoming implementations, make it exciting for developers to update their code * Document known demos and apps using the web audio API as a way to contact them when needed. Also as a way to promote/thanks early adopters? * Publicise (more) aggressively the existence of the Monkey Patch(es) A lot of this can be done through our community champions. Let's not underestimate the massive goodwill of people who are eager to help us deliver a better API, faster. I would also like to reiterate my wish to see raw data about usage of specific interfaces in code already in the wild. CRogers mentioned some useful data points about how much some interfaces are being used. It would be great to know which of these can be shared and what granularity they offer. The key will be to agree on what constitutes "significant" adoption of this or that interface. Is one app with a million users significant? Probably not, as there must be a way to help the developers of the app update their code. How about a couple of libraries used in hundreds of pages? How about a thousand independent apps with ten thousand monthly users each? Olivier ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. -----------------------------
Received on Tuesday, 18 June 2013 13:55:10 UTC