- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Mon, 27 Oct 2014 12:42:06 -0400
- 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