- From: Travis Leithead <travis.leithead@microsoft.com>
- Date: Tue, 15 Nov 2011 18:24:14 +0000
- To: Travis Leithead <travis.leithead@microsoft.com>, 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: Travis Leithead [mailto:travis.leithead@microsoft.com] >Sent: Tuesday, November 15, 2011 10:14 AM >>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 My bad. The object returned from these async operations is _not_ a promise, but rather a standardized async operation (it has consistent APIs for getting error info, results, etc. However, it works seamlessly with the actual promise object which is documented here [4]. [4] http://msdn.microsoft.com/en-us/library/windows/apps/br211867(v=vs.85).aspx To be honest, I'm not entirely sure how to two objects interrelate. I'll do some digging on my side and try to find out. >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:24:49 UTC