RE: [promise] writing detailed spec of ProgressPromise & implementing it
Domenic Denicola <[email protected]>
| Newsgroups | gmane.comp.web.dom.general |
|---|---|
| Message-ID | <B4AE8F4E86E26C47AC407D49872F6F9F8D89D5D2@SN2PRD0510MB360.namprd05.prod.outlook.com> |
From: Yutaka Hirano [mailto:[email protected]] > 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.