RE: The reason PendingOp removed from Messaging API

>-----Original Message-----
>From: Robin Berjon []
>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 :-). 


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


The actual promise object works as described on this IE Blog post [3].


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


Received on Tuesday, 15 November 2011 18:15:00 UTC