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

On Thu, Aug 8, 2013 at 2:52 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Thu, Aug 8, 2013 at 7:12 AM, Takeshi Yoshino <tyoshino@google.com> wrote:
>> On Thu, Aug 8, 2013 at 10:24 PM, Domenic Denicola
>> <domenic@domenicdenicola.com> 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.
>
> [1] http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0727.html

Agreed, ProgressPromise should still only be used by things that are
true Promises - a single async operation that delivers its results at
the end.  The progress callbacks should only return things like a
number (0-1?) or a state enum
("unsent"/"opened"/"headers-received"/"loading"/"done") - something
cheap and non-essential, and only used to monitor progress of the
primary operation.

If you're really wanting to represent an operation which updates
multiple times, you want something else, which we're working on right
now - Stream/BinaryStream or EventStream or something else.

~TJ

Received on Thursday, 8 August 2013 22:34:37 UTC