W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2013

Re: VideoStreamTrack: takePhoto()

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 9 Apr 2013 07:10:34 +0100
Message-ID: <CADnb78hbcddVdBdThKew7N-8e4n7fSX9FDBQ46ERFJ5J1apSRw@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:42 UTC