- From: Oliver Hunt <oliver@apple.com>
- Date: Tue, 12 Aug 2008 00:13:09 -0700
- To: Garrett Smith <dhtmlkitchen@gmail.com>
- Cc: Web Applications Working Group WG <public-webapps@w3.org>
>> 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. Yes, when you open a local file it is not a problem, but you are missing the point I tried to make -- not everyone is running with your setup, but you are interpreting "it works fine for me" as meaning it will work fine for everyone else. It is not uncommon for a "local" file to not be local. Many people have non-local home directories for example, or use other network attached storage devices which may have lower bandwidth. Trying to put it simply, there's no way you can (as a developer) know the restrictions that might exist on the endusers connect, eg. varying network bandwidth: a 1mb transfer on a broadband connection may take seconds to transfer, but on a modem will take minutes; client I/O overhead: slow network home directories, or even reading off a floppy disk (*shudder*, but these things do still exist). This is ignoring the problem that users do not want a website that prevents them from using their browser, even if the pause is for just a few seconds. >> 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" The issue is not something that is solved by a dialog, as the user is not choosing to block your application, they are choosing to block the entire UI of the browser -- in other words: all the other websites they may have wanted to look at while waiting for the file read to occur are blocked. > Sounds like async reads would avoid the problem of locking the UI. > > Why don't you post up your ideas? Because I don't have any specific ideas :D -- but i would imagine something similar to the database api, with completion and error callbacks, etc I just want to head off any ideas of having synchronous APIs before we repeat any mistakes of the past. The most important thing to remember when dealing with IO is that there are many scenarios that can result in poor I/O performance most of which people will not think of when testing, so it becomes very easy to make sites that unintentionally "hang" the browser of the end user. Anyhoo, as Sam said there really needs to be a spec editor. > Garrett --Oliver
Received on Tuesday, 12 August 2008 07:20:04 UTC