- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Tue, 9 Apr 2013 07:10:34 +0100
- To: "Robert O'Callahan" <robert@ocallahan.org>
- Cc: Robin Berjon <robin@w3.org>, Randell Jesup <randell-ietf@jesup.org>, "public-media-capture@w3.org" <public-media-capture@w3.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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. > (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 06:13:06 UTC