- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Sun, 7 Apr 2013 11:47:40 +0100
- To: Travis Leithead <travis.leithead@microsoft.com>
- Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>, Alex Russell <slightlyoff@google.com>
On Wed, Apr 3, 2013 at 7:16 PM, Travis Leithead
<travis.leithead@microsoft.com> wrote:
> Anne, can you whip up a proposal on how the Media Capture APIs might look with Futures, as well as provide some sample code for us to digest?
IDL:
Future takePhoto();
Future getUserMedia(optional MediaStreamConstraints constraints);
(The events for takePhoto() would go away, convention is for
dictionaries to not be marked nullable so no "?" there. Bit unclear
why you used two different patterns for takePhoto() and getUserMedia()
for the same kind of task.)
Example:
obj.takePhoto().done(function(blob) { ... }, function(error) { ... })
obj.getUserMedia(...).done(function(stream) { ... }, function(error) { ... })
http://dom.spec.whatwg.org/#futures now has an introduction on how
futures can be composed to do more interesting things. E.g. to take a
photo and request some data meanwhile about the user from his
Example.org account and then only do something if both those
operations succeeded you could do:
Future.every(obj.takePhoto(), fetch("https://www.example.org/user")).done(...)
Futures are new, but Indexed DB uses something pretty close to them
(and will be retrofitted going forward), CSS font loading will use
them, lots of device APIs will start using them, and basically every
new API that follows the pattern of having either a result or
rejection should use them.
--
http://annevankesteren.nl/
Received on Sunday, 7 April 2013 10:48:08 UTC