- From: Travis Leithead <travis.leithead@microsoft.com>
- Date: Tue, 15 Nov 2011 18:14:22 +0000
- To: Robin Berjon <robin@berjon.com>
- CC: "kisubs.song@samsung.com" <kisubs.song@samsung.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
>-----Original Message----- >From: Robin Berjon [mailto:robin@berjon.com] >Sent: Tuesday, November 15, 2011 1:51 AM >On Nov 15, 2011, at 07:43 , Travis Leithead wrote: >> Note that in Windows 8, Promises were the design of choice for the >JavaScript projection of core windows services. For better or worse they >are _everywhere_ there. I'm not proposing we use that pattern, but wanted >everyone to simply be aware of that. If a spec is created (I'm _not_ >volunteering here), then I'd hope it would be compatible with the Win8 >promise design. > >It's probably me being incompetent, but I'm having a world of trouble >finding documentation for this on Microsoft's web site. I'm probably >missing a magical keyword, "Windows 8" isn't even a topic on MSDN. Would >you mind linking to the above? I've been meaning to look at the approaches >you've taken there as they seem to be very interesting. Here's a link to the "Windows.Media.Capture" namespace [1]. It lists all the objects related to the Windows 8 capture API (which is not necessarily aligned with any particular W3C proposal at the moment--various folks at MS are aware of this :-). [1] http://msdn.microsoft.com/en-us/library/windows/apps/br226738(v=VS.85).aspx The "promise" objects are any "Class" (yes I know the terminology is all wrong for JavaScript) that ends with "Operation". So for example, "AddEffectOperation" is the return value (a promise) from the MediaCapture.addEffectAsync() function [2]. [2] http://msdn.microsoft.com/en-us/library/windows/apps/br211961(v=VS.85).aspx The actual promise object works as described on this IE Blog post [3]. [3] http://blogs.msdn.com/b/ie/archive/2011/09/11/asynchronous-programming-in-javascript-with-promises.aspx >Concerning promises, and without in any way taking the risk that you'll end >up editing a potential promises specification, do you think that they'd be >a better approach than what we have now (which isn't really consistent)? Promises have certain characteristics that must be taken into account. First, they are fully async. Thus your API has to account for potentially many such operations ongoing at any moment in time. Sometimes this isn't desirable if such contiguous operations can have negative performance impacts on your UA. Second, the exact syntax varies from library to library (as noted in the blog post above). I think rather than going all the way and defining promises, I'd start by better coordinating how APIs that return async results manage 1) the ability to get the result value and 2) the method for obtaining error/success info. I've noticed some recent changes in FileAPI and IndexedDB that seem to be coordinating alignment changes in this area. Might be good to capture these in our "best practices for API design" wiki. -Travis
Received on Tuesday, 15 November 2011 18:15:00 UTC