Re: Strawman Promises consensus position, based on Thursday's telechat

Hi all,

The TAG is very surprised to see the attitudes on display here.

There is absolutely universal agreement that callback-using APIs are bad, and that no more should be produced. It is imperative that this spec not proceed further down the W3C process track with a callback-based API. More importantly than any process question, no implementer should consider implementing this API (or unprefixing an already-implemented version of it) as long as it still contains callbacks. The TAG will strongly (and formally) oppose both process and implementation moves in this regard.

If there are shipping implementations in two or more browsers that are callback-based, then that can be specified for interoperability as a legacy API. (And prefixed implementations might count for this purpose, given the `navigator.getUserMedia || navigator.webkitGetUserMedia || ...` code mentioned elsewhere in the thread.)

But it is still imperative to provide a promise counterpart before the spec proceeds any further, e.g. by using the return value alongside optional callback arguments. For an example of this, see the Web Audio spec's `decodeAudioData` [1], which has callbacks for legacy-compat, but also returns a promise.

Thank you,

Domenic Denicola
W3C Technical Architecture Group

[1]: https://webaudio.github.io/web-audio-api/#widl-AudioContext-decodeAudioData-Promise-AudioBuffer--ArrayBuffer-audioData-DecodeSuccessCallback-successCallback-DecodeErrorCallback-errorCallback