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

Domenic, your opinion is
 1. If the progress mechanism affects the existing Promise functionality,
it will break the Promise functionality.
 2. Otherwise, ProgressPromise should be defined out of this spec.
, is that correct?
People in this thread do not want to define ProgressPromise in the first
way I think.

Is it OK with you to define a kind of ProgressPromise interface in the
second way in Streams API?


On Fri, Aug 9, 2013 at 7:33 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

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