RE: The reason PendingOp removed from Messaging API

>-----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