- From: Domenic Denicola <domenic@domenicdenicola.com>
- Date: Thu, 8 Aug 2013 13:24:21 +0000
- To: Yusuke Suzuki <yusukesuzuki@chromium.org>, "www-dom@w3.org" <www-dom@w3.org>
- Message-ID: <B4AE8F4E86E26C47AC407D49872F6F9F878A94B0@BY2PRD0510MB354.namprd05.prod.outlook.>
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] On Behalf Of Yusuke Suzuki Sent: Thursday, August 8, 2013 04:15 To: www-dom@w3.org Subject: [promise] writing detailed spec of ProgressPromise & implementing it Hi, 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:25:03 UTC