Re: File Upload Status ?

>> 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