Re: File API Feedback

On Tue, Jun 30, 2009 at 1:38 AM, Jonas Sicking<jonas@sicking.cc> wrote:
> On Mon, Jun 29, 2009 at 11:52 PM, Garrett Smith<dhtmlkitchen@gmail.com> wrote:
>> Progress-type Events are useful because the API is asynchronous.
>> What if reading the file times out?
>>
>> If an entire directory is uploaded, as in the Picasa-style example,
>> when does the "success" callback fire?
>> 1) after all files in "stress" are successfully read
>> 2) upon completion of each file
>>
>> When reading one large file (a movie, for example), how will the
>> program provide notification of progress of the upload?
>
> I think you might be misunderstanding the proposed API.
>
> The API simply allows reading files from the local file system (once
> the user has elected to grant the page access to a file).
>
> The proposed API is *not* for sending files to a server, for example
> in a Picasa-style app.

The picasa-style example mentioned earlier uses the word "upload".
I've not used Picasa, but it appears to read files off a local
network.

It is expected that XMLHttpRequest Level 2 will
> provide that functionality. Since XMLHttpRequest will be used, you'll
> have access to the full range of features available in XMLHttpRequest
> Level 2, such as ability to monitor progress, error and success.
>

OK. What does that have to do with reading a file off the local network?

> So, the scope of the current File API draft is limited simply reading
> files from the local file system.
>
> With that in mind, do you still think it makes sense to have progress
> events and all the other events you are proposing?

I've reread my message. The arguments and reasoning given for Events
seem clear and concise. The argument for Progress Events was
illustrated with an example and a comparison. What was confusing?

Garrett

Received on Tuesday, 30 June 2009 23:23:00 UTC