Re: Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)

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