Inconsistent behavior of $q notify

[torifat]

I have opened an issue in the original Q repo too. Angular implementation also has the same problem.

kriskowal/q/issues/445

[petebacondarwin]

Hmm, we should wait until there is consensus on what is the correct behaviour before making any changes to $q.
My personal feeling is that notifications should not be provided "after-the-fact" to handlers. Calling notify synchronously before any handlers can attach seems a strange case. What is the practical application of this?

[torifat]

@petebacondarwin Yes. Consider this http://www.bennadel.com/blog/2427-Using-jQuery-Deferred-notify-To-Provide-Locally-Cached-Data.htm

And, I think "Kris Kowal" has explained it nicely in his comment.

It would be reasonable to guarantee that the progressed handler be guaranteed to receive at least one notification if notify is ever called, with the last-known progress. Would also be also be reasonable to guarantee that the progressed handler gets called before the fulfilled or rejected handlers, since these imply a 100% progress notification.

[torifat]

@petebacondarwin Did you get what you want? Please let me know if you need further clarification.

I can help to implement it too but first I need to know your thought about it.

[lgalfaso]

with kriskowal/q#445 (comment), it looks like if we want to stay with notify, then we will have to live with this issue. If at a later point in time we want to follow Q use of estimates, then we should use another issue. At the moment, I think it is ok to close this issue