Re: File Upload Status ?

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

Received on Wednesday, 13 August 2008 03:02:04 UTC