Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A simpler notion of progress #7

Open
briancavalier opened this issue Mar 3, 2014 · 5 comments
Open

A simpler notion of progress #7

briancavalier opened this issue Mar 3, 2014 · 5 comments

Comments

@briancavalier
Copy link
Member

We've been discussing a simpler idea for progress over at cujojs/when#264. The essence is that if you restrict progress values to being numbers between 0 and 1, combining them is easy. It rules out the use of arbitrary values for progress, but to me, that's a win.

I figured I'd cross-link here for potential discussion since it's a fairly different approach.

@skaegi
Copy link

skaegi commented Mar 6, 2014

I think something very simple like what you describe would be very useful. One thing we've been wondering about is aligning with http://www.w3.org/TR/progress-events/ as perhaps that might be something used with promises in future W3C specs.

@briancavalier
Copy link
Member Author

@skaegi thanks for the link. It seems like the w3c's ProgressEvent is specific to something like XHR, since it has a loaded field--the name pretty strongly implies "number of things loaded" (where things === bytes for XHR). It might fit better with something as generic as promises if that field were named "completed", or "current". You're right, though, it's basically the same as the 0.0-1.0 notion.

In the issue thread I mentioned above, I think I've come to the conclusion that ETA may be a better/simpler notion in many cases. Combining percentages for parallel operations is easy, but I think is tough for sequential operations unless you have visibility to the entire sequence (or at least, you know how many operations are in the entire sequence). Promises in a promise graph only know about their immediate neighbors. ETA is easy for sequence and parallel operations (see the thread for more info). So, anything sum-based, like total, is probably similarly easy.

However, one problem with combining total is units. If several promises are producing total and completed (ie loaded) values with heterogenous units (eg bytes read, elapsed time, and steps completed in a wizard, etc.), it becomes nearly impossible to combine them in a meaningful way. That's where something standard like percentages or ETA helps.

@domenic
Copy link
Member

domenic commented Mar 11, 2014

Yeah, ProgressEvent is obsoleted by http://xhr.spec.whatwg.org/

@briancavalier
Copy link
Member Author

@domenic thanks! The whatwg xhr spec looks like it absorbed the previous ProgressEvent spec nearly verbatim. Am I reading that right, or has it been tweaked/evolved?

@domenic
Copy link
Member

domenic commented Mar 11, 2014

I'm not entirely sure of the history; usually W3C specs copy WHATWG specs (and thus WHATWG specs are more up to date, since the W3C snapshots only occur periodically). Certainly it looks like later revisions of ProgressEvents were extracted from XHR. In this case I think the work started in ProgressEvents before moving to XHR a year ago; since then it's been the familiar WHATWG -> W3C snapshot process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants