On Aug 11, 2008, at 11:21 PM, Garrett Smith wrote:
The other problem is that setTimeout does not result in async
javascript
execution it merely delays the synchronous execution of a script.
I've just tried to upload a 1.1mb log file from my hard drive and had
no issue reading. Using Firefox an older mac.
Reading a 46mb files was slow. I somewhat expected that.
Uploading large files will take time.
Consider that we need this API to work well not only on your system,
but also under scenarios that have much higher latency to disk, and
much lower bandwidth from disk, such as:
- network fileshares
- mobile devices with full browsing but limited hardware (such as the
iPhone or the Nokia e71).
Under these circumstances, reading even a small file can take orders
of magnitude longer than your measurements.
Your testing illustrates exactly the problem with having a synchronous
API at all: Web developers will test only on their own system, and
assume because that is fast enough then a hardcoded limit like this is
ok.
We've seen the result of this with synchronous XMLHttpRequest, where
almost any site using it leads to pervasive UI hangs for users on slow
networks. Let's not repeat that mistake with file access.
In your
example you are returning from readFile (to prevent your code from
blocking
the UI) and then the moment the timer is triggered a synchronous
read of a
definitely large file will occur, resulting in the UI being blocked.
That is not what the code was intended to do. I realize that I had a
recursive call in the function readFile. The intention is to
setTimeout(getFileContents, 1);
A useful error might be:
"error: file size over allowed limit."
Or in another context:
"warning: this file may take time to upload"
setTimeout will not prevent a long-running operation from blocking the
UI. It will merely defer blocking the UI to slightly later. Putting up
an error is not a good user experience.
The only way to prevent such UI blocking is to have an async api
regardless
as to whether you have a synchronous one, meaning that the
synchronous api
will only exist to either increase complexity (as developers will
need to
implement logic to fallback to, and implement, the async I/O in
addition to
the synchronous I/O logic as your above example would need to), or to
produce sites that fail to account for non-fast I/O (which thus
destroy the
end user experience).
Sounds like async reads would avoid the problem of locking the UI.
Why don't you post up your ideas?
We'll probably make a proposal for async reads in time. Our initial
implementation in WebKit only lets you upload a File object via XHR
but we believe eventually some form of direct I/O should be added.
Regards,
Maciej
