Some of the promises libraries now implement progress. The key thing that has yet to be decided upon is how we should deal with exceptions thrown in progress handdlers.

It has been broadly agreed upon that progress should be a single value (akin to fulfillment and rejection). We have also agreed that the third argument to then should be treated as the progress handler and should also controll propagation of progress.

I'd apreciate it if someone could fill in what the currently in use rules are regarding progress propagation.

We've been discussing a simpler idea for progress over at cujojs/when#264. The essence is that if you restrict progress values to being numbers between 0 and 1, combining them is easy. It rules out the use of arbitrary values for progress, but to me, that's a win.

I figured I'd cross-link here for potential discussion since it's a fairly different approach.

Do we need to support propagating more progress events than we recieve?

promiseA
  .then(null, null, function (val, prop) { prop(0); prop(1);});

Maybe github has changed something but it does not link to the issues.

Sorry for jumping out suddenly. I have read a lot about your dicussion and got some thoughts in my head about presenting a reasonalbe value for progress.

My solution is to introduce a concept called fraction. The fraction indicates how complicated do you think the promise is compared to its directly parent promise. By default it's 0.5, which makes the following 2 statements are equal.

prms.then(undefined, undefined, function(progress){});
prms.progress(fcuntion(progress){}, 0.5)

Setting fraction to 0.5 may lead to '50%-for-many-50%-for-one' and 'fast-slow' issues (they are same in rough). So if you think the parent promise is much more complicated, 0.1 may be a more proper value for fraction.

If the library itself can handle the calculation for progress, maybe 'value-to-propagate' and 'feedback-for-callbacks-completion' can be saved to leave progress lightwieght. If there are more complicated situations need to be handled, general in-out message mechanism can be called. Things like 'partial' can be handled with something like this:

var prms = new Promise(function(resolver) {
    var feedbackPrms = resolver.notify('partial', partialValue);
});

prms.listen('partial', function(value) {
    // Do something with the partial result 'value'
    return valueToPropagate;
});

What is on the inverse side is out-in message. I have seen other developers implemented cancel pause resume, and there is no reason people won't ask for more. So may be the general message mechanism is a one-for-all solution. Like this:

var prms = new Promise(function(resolver) {
    resolver.register('pause', function(){
        // Do pause stuff
    });
});

var pausePrms = prms.invoke('pause');

See #1

Progress handlers should be allowed to explicitly stop progress propagation. The trend in #1 seems to be toward allowing handlers to throw a duck-typed "stop propagation" error.

What should this error look like? One option is to follow builtin Error convention and have it be an Error whose .name == "<some specific name>", since we can't rely on instanceof across implementations.

Two related questions:

1. Would it be better to return such an error rather than throw it?
2. Would it be ok to allow returning such an error in addition to throwing it?

My instinct is that we should only support throwing the stop propagation error.

See #1 and #2

If we allow throwing a "stop propagation" error, what do we do with other exceptions thrown by progress handlers?

#5 is concluding with an updated draft (https://gist.github.com/4400252) and an implementation. We now need a list of progress use cases and see if the behavior that flows from the spec is as expected.

This has lots of holes in it, I'm putting it here though, because I'm hoping that we'll start to see where the holes are and fill some of them in a little.

Progress/A+

This proposal specifies how progress is triggered and propagated in a PromisesA+ promise library.

Requirements

The then method

The then method is the same as that specified in the promises-spec except that it also takes a third argument. We'll call that third argument the onProgress.

The onProgress

1. If the onProgress is not a function
   1. It is ignored
2. If the onProgress is a function
   1. When progress is emitted, the onProgress is called with the ProgressValue as the first argument.
   2. If the onProgress throws an exception with a .name property equal to 'StopProgressPropagation' then the error is silenced and progress is not propagated. In all other cases, the result of the function is used as the progress value to propagate.
   3. onProgress is never called once a promise has already been fulfilled or rejected.

The progress method

The resolver has a .progress(value) method. This triggers all the onProgress methods. It returns a promise which is fulfilled with undefined once all progress methods are complete or is rejected with the first (non-StopProgressPropagation) exception thrown by the handlers, if any.