- From: Aaron Boodman <aa@google.com>
- Date: Sun, 11 May 2008 18:01:08 -0700
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: Chris Prince <cprince@google.com>, "Web API WG (public)" <public-webapi@w3.org>, Ian Hickson <ian@hixie.ch>
On Sun, May 11, 2008 at 5:46 PM, Maciej Stachowiak <mjs@apple.com> wrote: > Well, that depends on how good the OS buffer cache is at prefetching. But in > general, there would be some disk access. It seems better if the read API is just async for this case to prevent the problem. >> I see what you mean for canvas, but not so much for XHR. It seems like >> a valid use case to want to be able to use XHR to download very large >> files. In that case, the thing you get back seems like it should have >> an async API for reading. > > Hmm? If you get the data over the network it goes into RAM. Why would you > want an async API to in-memory data? Or are you suggesting XHR should be > changed to spool its data to disk? I do not think that is practical to do > for all requests, so this would have to be a special API mode for responses > that are expected to be too big to fit in memory. Whether XHR spools to disk is an implementation detail, right? Right now XHR is not practical to use for downloading large files because the only way to access the result is as a string. Also because of this, XHR implementations don't bother spooling to disk. But if this API were added, then XHR implementations could be modified to start spooling to disk if the response got large. If the caller requests responseText, then the implementation just does the best it can to read the whole thing into a string and reply. But if the caller uses responseBlob (or whatever we call it) then it becomes practical to, for example, download movie files, modify them, then re-upload them. - a
Received on Monday, 12 May 2008 01:01:44 UTC