- From: Domenic Denicola <domenic@domenicdenicola.com>
- Date: Fri, 9 Aug 2013 13:13:49 +0000
- To: Yutaka Hirano <yhirano@google.com>, Tab Atkins Jr. <jackalmage@gmail.com>
- CC: Jonas Sicking <jonas@sicking.cc>, Takeshi Yoshino <tyoshino@google.com>, Yusuke Suzuki <yusukesuzuki@chromium.org>, "www-dom@w3.org" <www-dom@w3.org>
From: Yutaka Hirano [mailto:yhirano@google.com] > 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? I don't believe that's what I'm saying. I am saying that ProgressPromise is a bad idea, no matter where it is defined, and for reasons that have nothing to do with breaking existing Promise functionality. > Is it OK with you to define a kind of ProgressPromise interface in the second way in Streams API? I think defining a streams API is a fine idea. I think that streams API should definitely *not* use or define any kind of ProgressPromise, i.e. it should *not* have a method like `AbortableProgressPromise<ArrayBuffer> read(n)`. It should instead simply have `Promise<ArrayBuffer> read(n)`. I have not yet gotten around to replying to Jonas's question as to why this is important, and will try to do so later today.
Received on Friday, 9 August 2013 13:19:24 UTC