- From: Chris Rogers <crogers@google.com>
- Date: Wed, 16 May 2012 12:07:26 -0700
- To: Marcus Geelnard <mage@opera.com>
- Cc: olli@pettay.fi, Chris Wilson <cwilso@google.com>, robert@ocallahan.org, Philip Jägenstedt <philipj@opera.com>, public-audio@w3.org
- Message-ID: <CA+EzO0kYcdF7DTx82FzN=bixtEbR1EnE=up2C5gYemB_Le94wg@mail.gmail.com>
On Wed, May 16, 2012 at 12:06 AM, Marcus Geelnard <mage@opera.com> wrote: > Den 2012-05-16 01:54:17 skrev Chris Wilson <cwilso@google.com>: > > > Unless the W3C Recommended API is named "webkitAudioContext", this >> shouldn't be too much of a problem. >> >> Seriously, though - no, we do not want to arbitrarily break the games and >> other apps that have gone out already using early versions of the Web >> Audio >> API, but we are committed to migrating those apps over to a standard API >> that works across browsers, whatever that API might be. While I agree our >> evangelism has not been quite perfect in terms of clearly delineating >> experimental and early APIs, I would point out that in our more recent >> efforts (e.g. recent articles on HTML5Rocks), we've been purposefully >> improving that, and even with that admission, I would not characterize our >> past efforts as heavy evangelism for production apps. And it currently >> *IS* the only solution for audio processing in Chrome; we certainly hope >> to >> improve it and turn it into a cross-browser standard API, but we've never >> presented it as such that I know of. >> >> At any rate - we can absolutely take breaking changes - for some features, >> even under our webkit prefix. I don't know, to use one example, how >> quickly we could remove "noteOn" after adding "start", under the webkit >> prefix- I wouldn't want to break Angry Birds, etc., although I'm happy to >> go evangelize that they need to change their code for such changes >> (presuming there's an actual reason and it's not gratuitous). After all, >> that's my job. >> > > I don't really see this as an issue. We could have two audio API:s during > a transitional period: > > * The WebKit prefixed version, which basically stays as it is today and > continues to support legacy applications that are unlikely to migrate to > the new API in a timely manner. > * The un-prefixed cross-browser "standard" version. > > The fact is that whatever the audio API will look like, it will stay > around for a very long time - and I think the Web deserves a good, > sustainable audio API, so let's not push something just because of legacy > support (there are already too many examples of that in the computer > industry). > > /Marcus > Hi Marcus, I'm not sure that this approach of supporting two versions in WebKit (the prefixed and un-prefixed standard version) aligns with Robert's concern about "overhang", where there might be some subset (perhaps large) which will only work in WebKit browsers. But, if you're talking only about a "transitional" period instead of supporting two versions in WebKit forever, then maybe that could work. Chris > > > As the standard stabilizes, I'd expect we would all implement unprefixed, >> and it would reflect whatever is in the spec. If late-breaking changes >> come up, we would have to break people. >> >> -Chris >> >> On Tue, May 15, 2012 at 4:37 PM, Olli Pettay <Olli.Pettay@helsinki.fi>** >> wrote: >> >> On 05/16/2012 02:15 AM, Robert O'Callahan wrote: >>> >>> On Wed, May 16, 2012 at 10:33 AM, Olli Pettay <Olli.Pettay@helsinki.fi< >>> **mailto: >>> >>>> Olli.Pettay@helsinki.**fi <Olli.Pettay@helsinki.fi>>> wrote: >>>> >>>> On 05/16/2012 01:26 AM, Robert O'Callahan wrote: >>>> >>>> One thing that is going to be really important when addressing >>>> this feedback is understanding the existing compatibility constraints. >>>> As I >>>> said in an >>>> earlier email, if Webkit is unwilling to take a change, due to >>>> compatibility concerns, then we probably don't want to take that change >>>> in >>>> the >>>> spec either. >>>> >>>> >>>> What compatibility concerns? We're talking about an early draft of a >>>> spec, which is even implemented prefixed. >>>> Changing the spec sure should be possible. >>>> >>>> >>>> Google has heavily evangelized use of Web Audio in production apps. It >>>> has been presented as *the* solution for audio processing, without >>>> caveats. >>>> >>>> >>> That sounds like a bug in Google evangelism process. Or is it the case >>> that they have evangelized for >>> Chrome Web Apps (or whatever is the right term). Those are in a walled >>> garden, so not really part of the web. >>> >>> >>> -Olli >>> >>> >>> >>> Google people told me they're not willing to break compatibility with >>> the >>> >>>> content created under those assumptions. >>>> >>>> Rob >>>> -- >>>> “You have heard that it was said, ‘Love your neighbor and hate your >>>> enemy.’ But I tell you, love your enemies and pray for those who >>>> persecute >>>> you, >>>> that you may be children of your Father in heaven. ... If you love those >>>> who love you, what reward will you get? Are not even the tax collectors >>>> doing >>>> that? And if you greet only your own people, what are you doing more >>>> than >>>> others?" [Matthew 5:43-47] >>>> >>>> >>>> >>> >>> >>> > > -- > Använder Operas banbrytande e-postklient: http://www.opera.com/mail/ >
Received on Wednesday, 16 May 2012 19:07:56 UTC