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

Re: Proposal for an extension XMLHttpRequest to allow sending files

From: Maciej Stachowiak <mjs@apple.com>
Date: Thu, 17 Jul 2008 16:06:26 -0700
Cc: Sam Weinig <weinig@apple.com>, Web Applications Working Group WG <public-webapps@w3.org>
Message-Id: <47A39EF8-98D4-468F-8B62-A1F0063E0340@apple.com>
To: Aaron Boodman <aa@google.com>

On Jul 17, 2008, at 3:53 PM, Aaron Boodman wrote:

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

I agree! But this proposal doesn't include a concept of 'large chunk  
of binary data', only a concept of 'file'. It just lets you send the  
file without first turning it into a chunk of binary data. We're not  
proposing that the File object should be a generic representation for  
any binary data, just that it should be sendable via XHR directly.

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

So far the other requests we have had for this functionality have not  
needed slicing capability, but nothing in our proposal precludes  
adding it (even adding it in a way that's identical to the Gears  
proposal would be possible).

Received on Thursday, 17 July 2008 23:07:07 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:11 UTC