Re: Proposal for an extension XMLHttpRequest to allow sending files

On Jul 17, 2008, at 1:23 PM, Aaron Boodman wrote:

>
> Is the only difference from the Gears proposal the name of the object
> ("File") and the lack of reading APIs initially?

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

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.

As Sam mentioned, overloading send() to take a File does not preclude  
later overloading it to take a Blob or ByteArray or any other kind of  
object representing raw data.

Regards,
Maciej

>
>
> - a
>
> On Thu, Jul 17, 2008 at 1:14 PM, Sam Weinig <weinig@apple.com> wrote:
>> We would like to propose standardizing a way of using  
>> XMLHttpRequest to send
>> files to the server.  We propose using a similar (and compatible)  
>> API to the
>> Blob based API proposed by Google Gears
>> (http://code.google.com/p/gears/wiki/BlobWebAPIPropsal), but  
>> instead of
>> sending Blob objects, the File objects would be sent.  This will  
>> allow the
>> common act of uploading files, now relegated to form submissions  
>> with an
>> <input type="file">, to have access to ProgressEvents and the  
>> ability to
>> abort mid way through.
>> As with the Blob API, this is reuses the File and FileList interfaces
>> exposed by Mozilla
>> (see http://developer.mozilla.org/en/docs/nsIDOMFile and http://developer.mozilla.org/en/docs/nsIDOMFileList)
>> in a compatible.  We are not proposing a specific way to get the  
>> contents of
>> the files, but that would be a natural future extension.  Other  
>> potential
>> future extensions would be access to the icon associated with the  
>> file.
>>
>> Objects implementing the HTMLInputElement interface must also  
>> implement the
>> FileHTMLInputElement interface.
>> interface FileHTMLInputElement {
>>   readonly attribute FileList files;
>> };
>>
>> The files attribute must return a FileList containing all the files
>> currently selected.  This list is live, and therefore updates if  
>> contents of
>> the input element change.
>> interface FileList {
>>   readonly attribute unsigned long length
>>   [IndexGetter] File item(in unsigned long index);
>> };
>>
>> Each item in the FileList is File, which is a token representation  
>> of file
>> on the system.  The fileName attribute returns just the name and  
>> not the
>> complete path.  The fileSize attribute returns the size of the file  
>> in
>> bytes.
>> interface File {
>>   readonly attribute DOMString fileName;
>>   readonly attribute unsigned long long fileSize;
>> };
>>
>> Sending a File can be accomplished with an extension to  
>> XMLHttpRequest that
>> overrides the existing send() method.
>> Objects implementing the XMLHttpRequest interface must also implement
>> the FileXMLHttpRequest interface.
>> interface FileXMLHttpRequest {
>>   void send(File data);
>> };
>>
>>
>> -Sam Weinig
>>
>

Received on Thursday, 17 July 2008 22:42:15 UTC