RE: [promise] writing detailed spec of ProgressPromise & implementing it

I would strongly advise against conflating progress (ongoing notifications about a streaming async operation) and promises (one-and-done async operations). The promise implementer community in general, and the Promises/A+ organization in particular, has found this to be an extremely problematic line of reasoning, and one that does not mesh well with the existing semantics or syntax of promises. It has led to increased confusion from our users and a muddling of the underlying conceptual model, especially e.g. as it pertains to error handling. The fact that any progress additions to the promise API have no place in a shallow coroutine-based syntax enhancement of promises (e.g. C#’s await, or ES6’s yield) further strengthens our view.

As such I would ask you to consider alternate APIs that do not involve awkwardly stuffing streaming async semantics into one-and-done promises. For example, whichever object vends promises could be an EventTarget emitting progress events, or could instead of vending promises directly vend { promise, progressEmitter } pairs.

If this is part of the desire for a stream API, then I’d reiterate my earlier question to ask which API proposal is actually under discussion?

From: [] On Behalf Of Yusuke Suzuki
Sent: Thursday, August 8, 2013 04:15
Subject: [promise] writing detailed spec of ProgressPromise & implementing it


We're planning to make ProgressPromise spec more detailed and implement it on Blink experimentally.
ProgressPromise is planed to be used for some APIs, such as XMLHttpRequest / FileAPI.

Please feel free to comment about this.

Thank you,
Yusuke Suzuki

Received on Thursday, 8 August 2013 13:25:03 UTC