W3C home > Mailing lists > Public > public-device-apis@w3.org > November 2011

RE: The reason PendingOp removed from Messaging API

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>
Message-ID: <9768D477C67135458BF978A45BCF9B38381A199A@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
>-----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
>particular W3C proposal at the moment--various folks at MS are aware of
>this :-).
>[1] http://msdn.microsoft.com/en-
>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-

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-
>>Concerning promises, and without in any way taking the risk that you'll
>>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.
Received on Tuesday, 15 November 2011 18:24:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:51 UTC