RE: image capture and promises

I'll get out a revision either today or tomorrow, but to short-circuit this debate I'll be making setOptions() a promise as well.  We know that certain types of settings (e.g. e-mech camera zoom) are difficult to implement synchronously.

-Giri

-----Original Message-----
From: Jan-Ivar Bruaroey [mailto:jib@mozilla.com] 
Sent: Monday, October 27, 2014 9:42 AM
To: Martin Thomson; public-media-capture@w3.org
Subject: Re: image capture and promises

On 10/26/14, 6:19 PM, Martin Thomson wrote:
> This API could use promises, which would make it a lot clearer:
>
> [Constructor(VideoStreamTrack track)]
> interface ImageCapture : EventTarget {
>      readonly    attribute PhotoOptions     photoOptions;
>      readonly    attribute VideoStreamTrack videoStreamTrack;
>      readonly    attribute MediaStream      previewStream;
>      Promise<void> setOptions (PhotoSettings photoSettings);
>      Promise<Blob> takePhoto ();
>      Promise<Blob> grabFrame ();
> };

Isn't Giri already on it? [1] Last I looked Giri and roc were pushing for promises only [2]. In any case I support this.

> I'm not sure if there is any sense in having the setter for options be 
> asynchronous, but the accessor synchronous.  I guess it means that 
> photoOptions is a snapshot of a recent state of the stream.

If setOptions is synchronous then no promise would be needed obviously (I missed that earlier).

> Note that I also removed the nullable flag on the argument to 
> setOptions, that seemed odd.
>
> Also, it's not clear how previewStream actually helps here, over being 
> able to make a new MediaStream containing the video track (or using 
> the one that you would have extracted the track from).
>

[1]
http://gmandyam.github.io/image-capture/#promise-extensions-to-imagecapture

[2]
http://lists.w3.org/Archives/Public/public-media-capture/2014Oct/0208.html


.: Jan-Ivar :.

Received on Monday, 27 October 2014 16:50:53 UTC