- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 14 Jul 2014 09:47:19 +0200
- To: Arun Ranganathan <arun@mozilla.com>
- Cc: Web Applications Working Group WG <public-webapps@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>, Kyle Huey <me@kylehuey.com>
On Thu, Jul 10, 2014 at 7:05 PM, Arun Ranganathan <arun@mozilla.com> wrote: > On Jul 3, 2014, at 10:50 AM, Anne van Kesteren <annevk@annevk.nl> wrote: >> That would mean you would get different results between using >> FileReaderSync and XMLHttpRequest. That does not seem ideal > > The implementation train has already left the station on this. The movitation of an “ideal" match-up with XMLHttpRequest doesn’t seem strong enough to revisit this by filing browser bugs across implementations (but Cc’ing K. Huey also). Well, surely if we support both, we'd like them to work in the same way so they can share the same underlying abstraction. > We agreed some time ago to not have partial data. Pointer? I also don't really see how that makes sense given how asynchronous read would perform. > Then let’s have a different read operation that doesn’t use the FileReader Task Source. The primary API in File API uses the event loop (FileReader), so for that purpose, the existing read operation is important. Early discussions about this made me feel that a task queue based system to asynchronously read blobs could be reusable by Fetch, and by future Promise-based APIs. Yeah, I now think that we want something even lower-level and build the task queuing primitive on top of that. (Basically by observing the stream that is being read and queuing tasks as data comes in, similar to Fetch. The synchronous case would just wait for the stream to complete. -- http://annevankesteren.nl/
Received on Monday, 14 July 2014 07:47:45 UTC