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

On Thu, Aug 8, 2013 at 10:24 PM, Domenic Denicola <
[email protected]> wrote:

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

It's discussed with a name "ProgressPromise" but I think what we need and
drafting and Promise are not cleanly under as-is relationship (for example,
data represented by ProgressPromise will be CONSUMED by progress callbacks
already set and already consumed partial sequence of data won't be
delivered to callbacks set later). For Streams API (and maybe also for
fileapi), it would be useful if we build and use something lazily delivers
possibly infinite sequence of data + end signal + failure.

It would be similar to Promise from some point of view, and maybe we'd
reuse lots of code now used for Promise to implement it. So I'm discussing
it together with Promise.