W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Fwd: File Upload Status ?

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Mon, 11 Aug 2008 20:13:11 -0700
Message-ID: <c9e12660808112013q738ba58p50beec46babdd331@mail.gmail.com>
To: "Web Applications Working Group WG" <public-webapps@w3.org>

---------- Forwarded message ----------
From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Mon, Aug 11, 2008 at 8:12 PM
Subject: Re: File Upload Status ?
To: Sam Weinig <weinig@apple.com>


On Mon, Aug 11, 2008 at 7:41 PM, Sam Weinig <weinig@apple.com> wrote:
>
> On Aug 11, 2008, at 7:30 PM, Garrett Smith wrote:
>
>> On Mon, Aug 11, 2008 at 7:18 PM, Sam Weinig <weinig@apple.com> wrote:
>>>
>>> Just a few weeks ago
>>> (http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0186.html)
>>> I
>>> proposed a stripped down version of the File Upload spec (thinking it
>>> defunct) that matched Mozilla's implementation sans the data accessors.
>>> One reason for not including the data accessors was that we don't think
>>> synchronous access to the disk is a good idea and browser.
>>>
>>
>> Sam,
>>
>> I got that you don't think it's a good idea, but not why. Also, I
>> don't understand the 'browser' at the end. Can you explain this?
>>
>> Please quote what you are replying to so to make it clear as to
>> exactly what you're replying. IM lost.
>>
>
> Sorry, the "and browser" at the end was a typo.  I meant to say, "in the
> browser".  The reason synchronous access to the disk is a bad idea is that
> if the operation takes too long, a big file, a slow network home directory,

Then:

function readFile(file) {
// 1. Check the fileSize property.
 if(file.fileSize > 100000) {
   generateFileWarning(file);
   return;
 }
 // 2. read file asynchronously.
 setTimeout(readFile, 1);
}

seems to completey address the problems you mentioned in only a few
lines of code.

> or for whatever other reason, the browser hangs.  It is the same reason
> synchronous network access can be construed as a bad idea.
>
> I was replying to your request for implementors to give you feedback.  I am
> in favor of spec moving forward, but it needs an editor.
>

I know that you were replying to my request for implementors to give
feedback. I was confused about what specifically you were replying to
in what I wrote before.

I'd like to see if we can work together to define the best strategy
for this. Another possibility is passing the file directly to the XHR.
The benefit of this is dealing with the boundary issue in a
multipart/form-data request. The problem with mutipart/form-data
(besides being complex and messy) is that the boundary exists in the
request data, and also in a request header. Building
multipart/form-data by hand is painful.

Thoughts?

Garrett

> -Sam
>
>
>
>
Received on Tuesday, 12 August 2008 03:13:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:27 GMT