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

Re: VideoStreamTrack: takePhoto()

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 09 Apr 2013 09:21:16 +0200
Message-ID: <5163C16C.7070603@alvestrand.no>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:16 UTC