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/[email protected]
[2] http://www.w3.org/mid/[email protected]
