Audio WG Meeting -- 20 Jun 2013

<padenot> ha

<ehsan> padenot is also from Mozilla

<olivier> Scribe: chrislowis

<olivier> ScribeNick: chrislowis

olivier: I'd like us to spend a while discussing the current state of implementations (Webkit, iOS 6/7 Blink, Opera and Mozilla). How are we going to deal with the prefixing of AudioContext in docs and implementations?
... I realise that some of this is not strictly speaking spec-building, but more about getting the implementors around the table to discuss a difficult issue.
... I'll try and summarise:

We've had a few changes recently to some of the interfaces in the spec.

At the f2f in March we had an interesting flip-flop of decisions - first deciding that the old interfaces would be clearly deprecated, and decided that that would be difficult and put to much strain on the implementations. Instead we decided that we would (normatively) support both names for things.

Since that decision at the meeting, there has been a change of heart that supporting both interfaces has problems.

Mainly that due to implementations arriving at different times, there may be some issues in doing this.

We need to find a path through this that makes it fair for all sides, but also is the right decision for the future.

Perhaps we can take a couple of minutes for each implementor to talk about their ideal outcomes.

ehsan: Sure. First the ideal outcome from my position, then the worst possible outcome.
... The ideal outcome is to have a good, clean and pleasant API for developers that is available across multiple implementations.
... I think the best way to get there is for Gecko, Webkit and Blink to ship compatible implementations all at the same time.
... what belongs in those implementations is a different conversation that we should have.
... ideally if everyone ships at around the same time, then it sends a message to web developers that this is an api that they can trust and use.
... the significance of shipping an unprefixed implementation is that once it is shipped, it is diffcult to change anything after that point.
... since, historically this has happened with prefixed implementations before, and it is how they are perceived on the web.
... the least desirable outcome is that one or two of the implementations continue to ship their prefixed versions for an extended period of time.
... the implementation that is prefixed for the longest period of time, is the one that is going to have a problem removing something in the future.
... as from the point of view of users that will be the implementation will be considered to be broken.
... since webkit has been shipping for the longest period of time at the moment, there won't be a lot of incentive for developers to check their code against other versions such as gecko.

olivier: Chris Rogers, could you play the same exercise for us? The best and worst case.

crogers: I think we should go with the decision we made at the f2f that we should go with the duplicate names in the unprefixed version, which will cause us and developers the least amount of problems.
... it will solve most of the compatability problems, and browsers can ship an unprefixed version.
... the second best outcome is to make the old names an "historical note" in the spec. We'd need to support the old names in the prefixed AudioContext, and we would all have to help evangalise to help get devlopers off the old names and onto the new ones.

<jernoble> cq

crogers: we know from an experimental build internally, that even shipping an unprefixed version will break about 75% of content.
... As far as making any additional stylistic changes, now is absolutely not the right time for that. I will push back on any changes that I think are not being made for technical reasons.

olivier: by that you mean changes that are not for technical reasons, but ones that are considered "better looking".

crogers: yes. For example changing create methods to constructors, which would be a massive breaking change. And changing async callbacks to use promises, would also be a serious change.

olivier: We have Jer on the queue

<jernoble> i seem to be muted

jernoble: I largely agree with what has been said about the best and worst perspective.
... from our perspective, if there is going to be breaking API changes, we *cannot* unprefix.
... and if there is going to be any more changes like that, we won't be able to.
... where I disagree with crogers is that there is no point renaming things if we're not going to remove them so we should go ahead and do that.

olivier: so to summarise, we need to be sure that the API is rather stable, and then and only then will you be ready to un-prefix.

jernoble: that's correct. So removing somthing is a breaking change, but adding something is not.

crogers: I don't understand why you'd be comfortable taking aliases out. That would be a breaking change?

jernoble: yes. From our point of view, things behind a prefixed API are playing "fast and loose" with emerging technology. Once unprefixed it has to be solid.

crogers: so the change to PeriodicWave from WaveTable?

jernoble: yes, that would be fine while we're prefixed but not afterwards.

olivier: Next on the queue is ehsan.

ehsan: Once a browser is shipping an unprefixed API, it is hard to make changes.
... it's much easier with a prefixed API. The bar is lower.
... that's why I'd like a timeline for when the other implementors will ship, so we can make a decision based on that.
... a comment on why I made the change in opinion from the f2f conference:
... when I got back from that I got a lot of push back from other people in Mozilla and on our IRC channels, that we were effectively supporting a defacto standard.
... so it's going to be a pragmatic decision on our part, that we will be making a decision that we will support something that is codified in the spec, but not exactly what will be implemented by developers in practice.
... so I'd like to discuss the timing of if/when things will be changed, and the other is what changes will be made.
... I think we should remove the synchronous api calls from the spec, as we cannot justify that in an API.
... with regards to alternative names in the spec. I believe the issue of alternative names is much more serious than the one about using constructors, or Promises.
... I'd like to take out of our discussion a timeline of when people hope to ship an unprefixed version. Without those timelines, all we are discussing is a bunch of ideas being brought back and forth - which won't mean a lot in practical terms. There's a difference between what will happen in 2 months versus 2 years.

olivier: all things being equal when would you, ehsan, think it would be a good time to ship AudioContext

ehsan: at the moment in FF24, Sept. 17th. See my post on the mailing list for more details.

olivier: and to you crogers and jeroble, what can you share with us about your timelines?

crogers: I would say, a ballpark figure would be between 3 and 6 months, but I'd need to coordinate with cwilso_, who's unavailable right now. It will depend on our testing, we'd like to test both versions, and get a developer version out in the wild to help people with any problems.

olivier: for the record: no one here is commiting to any release, this is just developers perspective.

jernoble: thank you for that caveat olivier. We have a slower release cycle. We tend not to ship new features between major releases. Apple just released a couple of beta versions to developers, which has some changes to the names. We do have time between now and when we release to the public to make other changes, including unprefixing, if we can get a commitment that there won't be any more breaking changes.

crogers: you can have a commitment from me! How soon do you need that locking down?

<ehsan> +q

jernoble: the sooner the better, as always. If we could commit to that in the next week or so that would be ideal.

crogers: and if we miss that, we'll have to wait another year or so.

jernoble: that's correct.

olivier: we haven't, as a W3C group at least, had our "last call" yet.
... that is the time when we would expect a considerable amount of feedback. And we can't guarentee that that won't throw up some important changes to be considered.

crogers: I understand what you're saying about there being a next stage. But the spec has been there for a long time now.

olivier: yes, and one outcome is that there is no feedback.
... but we shouldn't discount the possibility.

ehsan: < scribe missed the question >

crogers: if everyone is insistant that the alternative names should be removed, we will remove them from the unprefixed version.
... but it might alter our timeframe a little bit.
... the old names in the webkit prefixed version, we don't know how long it will take. That is a longer timescale.

ehsan: the webkit version won't be removed when the prefixed version is shipped?

crogers: yes, that's correct.

ehsan: that's bad news. It will mean the unprefixing won't matter in practice.

<shepazu> (that seems like an exaggeration)

crogers: the old names won't be in the prefixed version. It will be "pure". But we would also ship a prefixed version with the old names.

jernoble: it is apple's policy not to remove a prefixed version of an API when we ship a prefixed version.

<joe> +joe

jernoble: (although we would probably remove the old names from the prefixed version.)

olivier: I can guarentee that if everyone ships an unprefixed version today, in 6 months all developers will be using it. The number of sites using the prefixed version will be diminishingly small.

ehsan: I would like to question your assumption that everything will be fixed in 6 months. There will be no incentive for people to go and fix things, even things that a linked to from our own Wiki page.

shepazu: but, at the moment, there is only the prefixed version. As soon as there is an unprefixed version people will start to work on that.
... we have evangalism and MonkeyPatches available to help. I think developers will really want their code to work in Firefox.
... we have seen with CSS for example that over time prefixed versions are phased out and developers will get used to it.

joe: from this developers perspective, working on FF is an absolute requirement for any commercial application.
... we will need FF to work, so we will absolutely code to the unprefixed version.

olivier: joe that's a very valuable contribution, thank you.

ehsan: as of this moment I am unconvinced that we should ship a webkit-prefixed version. If we did it would be the first time this has ever happened in Mozilla.
... we have always taken the position that evangalism and education is the best way forward.

<olivier> list of suggested actions here: http://lists.w3.org/Archives/Public/public-audio/2013AprJun/0586.html

shepazu: we have mdn, html5 rocks and other documentations under our control, effectively. We can reach out and contact developers, and olivier has made some suggestions for other actions as above ^^.

olivier: I think we have to adjorn here.
... I'd like to share the minutes with everyone and get some feedback. I'll take an action to contact Jory and ask for his opinion on how to reach out to developers.
... and share this with cwilso_, in particular.
... thank you for your contributions today. It's been a good discussion, thank you.

- DRAFT -

Audio WG Meeting

20 Jun 2013

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output