W3C home > Mailing lists > Public > public-media-capture@w3.org > October 2014

Re: image capture and promises

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Mon, 27 Oct 2014 12:42:06 -0400
Message-ID: <544E75DE.2090905@mozilla.com>
To: Martin Thomson <martin.thomson@gmail.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
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:42:35 UTC

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