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

On Thu, Aug 8, 2013 at 7:12 AM, Takeshi Yoshino <> wrote:
> On Thu, Aug 8, 2013 at 10:24 PM, Domenic Denicola
> <> 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.

Hi Takeshi,

I'm not sure if we have different visions for what ProgressPromise
should be, or if I'm misunderstanding the above.

My vision has been that ProgressPromise *is* a promise. I.e.
ProgressPromise is a subclass of Promise. For any function that that
returns a ProgressPromise, the caller can simply treat the returned
object as a normal Promise and get the same behavior as normally
expected for promises.

However when a caller receives a ProgressPromise he/she can also use
the progress notifications to render progress UI for the user. So the
progress notification would usually contain something like a
percentage as to allow rendering a progress bar. Other times, when
that is not possible, other information that can be used to ensure
that the user is feeling like things aren't working. For example in a
filesytem API you don't know how many files live inside of a directory
tree, but you can provide the name+path of the current file.

I had not expected that we would provide actual data to the progress
callback. At least not in the common case. The concern I have with
providing the actual data is that this can be quite resource intensive
as we see with XMLHttpRequest.

If you constantly provide "here is the updated result that I have got
so far" information, that leads to having to allocate larger and
larger buffers of data, and many times copy data from old to new
buffers as the old buffers can no longer contain the data.

If you instead provide "here is what I got since last update", that
lessens the resource use, but then you don't really have a Promise any
more, but rather a Stream.

I think Stream and ProgressPromise are two different things. As
demonstrated by my proposal in [1] where the Stream primitive uses
ProgressPromise to return data.


/ Jonas

Received on Thursday, 8 August 2013 21:53:04 UTC