File API proposal - marrying two alternatives

I figure I could rewrite Jonas' proposal to make it more palatable (at  
least to me) and satisfy the use cases and priorities I mentioned in  
[1]. Here's his proposal to combine with File and FileData from the  
current ED.

interface FileData {
   readonly atribute DOMString url;
   readonly attribute unsigned long long size;

   FileData slice(in long long offset, in long long length);
};

interface File : FileData {
   readonly attribute DOMString name;
   readonly attribute DOMString mediaType;
};

typedef sequence<File> FileList;

[Constructor, Implements=EventTarget]
interface FileRequest {
  readAsBinaryString(in FileData filedata);
  readAsText(in FileData filedata, [Optional] in DOMString encoding);
  readAsDataURL(in File file);

  abort();

  const unsigned short INITIAL = 0;
  const unsigned short LOADING = 1;
  const unsigned short DONE = 2;
  readonly attribute unsigned short readyState;

  readonly attribute DOMString response;
  readonly attribute unsigned long status;

  attribute Function onloadstart;
  attribute Function onprogress;
  attribute Function onload;
  attribute Function onabort;
  attribute Function onerror;
  attribute Function onloadend;
};

My main issues are the following:

"File" interface is separate from FileData and that makes little sense  
at this time. Can't the two be merged in to "File"? (Use case 3 - all  
the metadata)
"FileRequest" should be renamed as "FileReader" as Arun pointed out [2].
The attributes "response" and "status" from the "FileRequest"  
interface make no sense. They are copy-pasted from XHR but their  
purpose is unclear. This is why I said that plainly copying XHR as the  
template for FileReader is not a good idea.
It'd be better to define the actual "FileRequest" separately from a  
factory of "FileRequest" objects. Consider what would happen if  a  
single "FileRequest" object is used multiple times to read as the same  
or different data types? What happens when I abort()? (Use case 2 -  
concurrent access & priority 2)
What is the meaning of LOADING and DONE? Once I create the reader, it  
should be in the LOADING state automatically. FileReader, unlike XHR,  
does not have an explicit send step.

Here's a proposal to resolve these issues.

interface File {
   readonly atribute DOMString url;
   readonly attribute unsigned long long size;
   readonly attribute DOMString name;
   readonly attribute DOMString mediaType;

   File slice(in long long offset, in long long length);
};

[Constructor]
interface FileReaders {
  FileReader readAsBinaryString(in File file);
  FileReader readAsText(in File file, [Optional] in DOMString encoding);
  FileReader readAsDataURL(in File file);
};

[Implements=EventTarget]
interface FileReader {
  abort();

  const unsigned short INITIAL = 0;
  const unsigned short LOADING = 1;
  const unsigned short DONE = 2;
  readonly attribute unsigned short readyState;

  attribute Function onloadstart;
  attribute Function onprogress;
  attribute Function onload;
  attribute Function onabort;
  attribute Function onerror;
  attribute Function onloadend;
};

Usage examples would be:

Current editor's draft:
myFile.getAsBinaryString(handler);
function handler(data, error) {
  doStuffWith(data);
}

Jonas' API:
reader = new FileReader;
reader.readAsBinaryString(myFile);
reader.onload = handler;
function handler(event) {
  doStuffWith(event.target.response);
}

This proposal:
var readers = new FileReaders;
reader = readers.readAsBinaryString(myFile);
reader.onload = handler;
function handler(event) {
   doStuffWith(event.target.response);
}

I would be fine with a new draft that uses the approach of Jonas with  
the details of the proposal in this message.

Nikunj
http://o-micron.blogspot.com

[1] http://www.w3.org/mid/AB855028-5F90-4816-BABD-6780579143BC@oracle.com
[2] http://www.w3.org/mid/4AB9AD9C.6070809@mozilla.com