W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2013

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

From: Domenic Denicola <domenic@domenicdenicola.com>
Date: Thu, 8 Aug 2013 13:31:14 +0000
To: Domenic Denicola <domenic@domenicdenicola.com>, Yusuke Suzuki <yusukesuzuki@chromium.org>, "www-dom@w3.org" <www-dom@w3.org>
Message-ID: <B4AE8F4E86E26C47AC407D49872F6F9F878A9520@BY2PRD0510MB354.namprd05.prod.outlook.com>
To be clear, I am trying to help the browser implementer community avoid the mistakes that we, the promise implementer community, have made in this regard. I truly believe that if the lessons of history are not learned in this case, then in a couple years ProgressPromise will be seen as a bad-practice vestigial part of the web platform, which is to be avoided in new APIs and which plagues existing APIs that use it with unnecessary complexity and limits their extensibility. This is exactly the situation we are now in with user-space promise implementations.

The web platform does not need more such APIs.

From: Domenic Denicola [mailto:domenic@domenicdenicola.com]
Sent: Thursday, August 8, 2013 09:24
To: Yusuke Suzuki; www-dom@w3.org
Subject: RE: [promise] writing detailed spec of ProgressPromise & implementing it

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.

As such I would ask you to consider alternate APIs that do not involve awkwardly stuffing streaming async semantics into one-and-done promises. For example, whichever object vends promises could be an EventTarget emitting progress events, or could instead of vending promises directly vend { promise, progressEmitter } pairs.

If this is part of the desire for a stream API, then I’d reiterate my earlier question to ask which API proposal is actually under discussion?

From: yusukesuzuki@google.com<mailto:yusukesuzuki@google.com> [mailto:yusukesuzuki@google.com] On Behalf Of Yusuke Suzuki
Sent: Thursday, August 8, 2013 04:15
To: www-dom@w3.org<mailto:www-dom@w3.org>
Subject: [promise] writing detailed spec of ProgressPromise & implementing it


We're planning to make ProgressPromise spec more detailed and implement it on Blink experimentally.
ProgressPromise is planed to be used for some APIs, such as XMLHttpRequest / FileAPI.

Please feel free to comment about this.

Thank you,
Yusuke Suzuki
Received on Thursday, 8 August 2013 13:31:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:03 UTC