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

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

Ah, OK! In that case, it sounds like you are talking about something more like a stream (incremental, ongoing async operation) than a promise (one-and-done). I definitely agree the web platform needs such a thing! I just was confused by the proposal I saw that implemented streams in terms of AbortableProgressPromises, in effect introducing *two* layers of incremental ongoing async data.

I would encourage looking at existing work here, including battle-tested approaches like Node's stream API but also some of the more clean-slate approaches such as [the simple-stream API][1] used in js-git.

In any case, I think the most important thing to keep in mind when designing such a primitive reusable part of the web platform is to make it as simple as possible, but no simpler. Meaning, it should not include extraneous features in the first version, such as mid-chunk aborting or mid-chunk progress, and it needs to be a simple-but-powerful core API so that it can be extended to include infrastructure such as writable streams (or sinks), piping, binary data -> string decoding, etc.

This is exciting! I just hope we can get it right.

[1]: https://github.com/creationix/js-git/blob/master/specs/simple-stream.md

Received on Thursday, 8 August 2013 14:43:56 UTC