See also: IRC log
<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.
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/changes/breaking changes/ Found Scribe: chrislowis Found ScribeNick: chrislowis WARNING: No "Topic:" lines found. WARNING: No "Present: ... " found! Possibly Present: Doug_Schepers HTML HTML_WG I18N_CoreWG IPcaller Jan Mozilla PROV RWC_Audio SW_ ScribeNick TF Team_ WAI_PFWG XML_QueryWG XML_XSLWG XSLT aaaa aabb aacc aadd active aut0mata chrislowis crogers ctpac ehsan gldc jernoble jernoble_ joe johnwbyrd mdjp olivier padenot shepazu You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://lists.w3.org/Archives/Public/public-audio/2013AprJun/0608.html Got date from IRC log name: 20 Jun 2013 Guessing minutes URL: http://www.w3.org/2013/06/20-audio-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]