- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 09 Apr 2013 09:21:16 +0200
- To: public-media-capture@w3.org
On 04/09/2013 08:10 AM, Anne van Kesteren wrote: > On Mon, Apr 8, 2013 at 10:54 PM, Robert O'Callahan <robert@ocallahan.org> wrote: >> It seems to me easy to add support for futures later, right? As in, we could >> ship the existing callback-based API and later the browser implementation >> can switch to futures internally, expose a DOM Futures API and easily also >> continue supporting the old API on top of futures. Suboptimal but not >> disastrous. > For a callback-based API that's relatively straightforward. For one > based on events you'll still need to keep all the event-related > machinery around which would suck. But since we can switch now I don't > see why we'd wait. It seems to me that futures (what I understand of them) are easily able to implement the "one query, one result" semantic of a callback-based API. I think event-based machinery is appropriate when the number of things that can happen is indeterminate (0, 1 or many); onaddstream is a typical example. Is there a version of futures that permits capturing this semantic too? > >> (This is different to mistakes like UTF-16, where widespread use of >> charAt()-like APIs makes switching implementations to UTF8 strings very >> challenging.) > (If indeed the choice was between those. And the mistake is 16-bit > code units, not UTF-16 (which cannot express surrogates). JavaScript > came out March '96, surrogates arrived July '96; could have been fixed > in time for NN4 I suppose...) > > > -- > http://annevankesteren.nl/ >
Received on Tuesday, 9 April 2013 07:22:39 UTC