Re: Proposal for an extension XMLHttpRequest to allow sending files

On Thu, Jul 17, 2008 at 3:41 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> The Gears proposal has a File object too, as does Mozilla's extension. We
> are proposing making the File object usable directly as an XHR body, so that
> we can all support file upload through XHR interoperably without first
> having to agree on the mechanisms for reading file contents and representing
> binary data (which are different between Gears and Mozilla).

Right, I see the difference now. It is basically:

Gears proposal:
xhr.send(inputElement.files[0].contents);

WebKit proposal:
xhr.send(inputElement.files[0]);

> File upload through XHR is useful even without a means to read the data
> client-side, because combined with progress events it can provide in-page
> progress UI with info for multiple files, which is quite a bit better than
> what you get with form submission. Currently some web apps use Flash for
> uploads solely to enable progress UI.

Yup, this is the main reason we proposed this API. Reading the data is
secondary and is not implemented in Gears today or planned for the
near term.

I have two minor concerns with this proposal, both in the cases where
it differs from Gears:

1. Combining the concepts of 'large chunk of binary data' and 'file'
seems unnecessarily coupled to me. It seems likely that in the future
the first concept would be useful in the web api by itself. For
example, in Gears, we have a xhr.responseBlob property. Having a
fileName property here would not always make sense.

2. The slice() method seems important for the initial version,
particularly if you are targeting the large upload use case. We use
this to cut up a large file into smaller pieces so that they can be
uploaded individually. This makes the upload resilient and also allows
the UI to show progress on the upload.

- a

Received on Thursday, 17 July 2008 22:53:58 UTC