On Aug 12, 2009, at 6:32 AM, Arun Ranganathan wrote:
Jonas Sicking wrote:
Here is an alternative proposal for an API for reading files:
[Constructor, Implements=EventTarget]
interface FileRequest {
readAsBinaryString(in FileData filedata);
readAsText(in FileData filedata, [Optional] in DOMString);
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;
};
Additionally, inside DOM Workers we could supply the following
interface:
[Constructor]
interface FileRequestSync {
DOMString readAsBinaryString(in FileData filedata);
DOMString readAsText(in FileData filedata, [Optional] in DOMString);
DOMString readAsDataURL(in File file);
};
As stated, I'm not convinced that this is a better solution than what
the spec currently does. The only advantage I can see is that it
supports progress events without requiring the use of XMLHttpRequest,
While the above API does have the advantages that we agree come with
a model that stems from EventTarget and events, I'm concerned that
we've complicated the API for an edge case. I *do* agree that
progress events are desirable, especially given leaky abstractions
for file systems (e.g. the user plugs in a networked drive, which is
surfaced from the input type="file" picker) which could behave
slowly. But this seems like a desirable edge case which we should
find another solution for, and not overhaul the entire API.
Do we need asynchronous APIs if files are local and file system access
is fast? If we do, then why do we not also need progress events? I
don't quite follow your reasoning and classification of "desirable
edge case". It seems that the whole WebApps WG has accepted the
"desirable edge case" of dealing with system delays such as in SQL
databases and file systems through the use of asynchronous APIs.
In fact, progress events for file APIs seem pretty sugary in
general; many of the other platforms I've looked at for File APIs
don't have them.
Please cite the platforms you have researched.
That's not to say that the web shouldn't have it -- I'm just
pointing out that I think most users of the API will simply call the
API to get the file. And, I think that in the lion's share of use
cases, things will behave rapidly enough to not warrant the use of
progress events (except during the networked/plugged in scenarios).
or for that matter asynchronous callbacks? Why do you think users will
want asynchronous callbacks in the "lion's share of use cases"?
Nikunj
http://o-micron.blogspot.com
So, I think we could investigate adding progress feedback without
changing the existing model.
Current draft:
myFile.getAsBinaryString(handler);
function handler(data, error) {
doStuffWith(data);
}
Above API:
reader = new FileReader;
reader.readAsBinaryString(myFile);
reader.onload = handler;
function handler(event) {
doStuffWith(event.target.response);
}
We can discuss adding progress feedback to the current draft via
another optional callback that is an argument to the asynchronous
data accessor methods, and we can make arguments on this callback
match those in ProgressEvents [1].
An example might be:
[CallBack=FunctionOnly, NoInterfaceObject] interface ProgressReport {
void handleEvent(in unsigned long loaded, in unsigned long total);
};
which we can specify is optionally used with the asynchronous data
accessors, and which (if provided) implementations will call within
the HTML5 event loop (like progress events, with the same frequency,
etc.). There may be other solutions as well.
The advantage is that we stick with the existing model, which I
honestly believe is simpler. The disadvantage is that we don't use
the full event model here, which is a trade-off (and as has pointed
out, there definitely isn't consensus on this). There's also a
general argument that's been made on the listserv for extensibility,
which I'm not sure I fully understand, since I think that even an
event model has similar problems.
Honestly, I don't like to use events for file access. I don't know of
another programming library that does. However, there needs to be a
way to separate the reading of a file from the file itself. Properties
of a file such as its length as well as a temporary URI belong on the
file. The rest that actually read its contents belong somewhere else.
This is how I grew up programming.
I'm perfectly amenable to changing the existing draft, which has
been updated based on earlier feedback [2], but I'd like to
emphasize that my reluctance to switch to a model such as the one
above is honestly for simplicity's sake. Ideally, authors will be
able to access files intuitively, using the simplest "language of
files" (get the file, do something with it).
I'd really like to hear from others, particularly implementors who
have been silent till now :-)
-- A*
[1] http://www.w3.org/TR/progress-events/
[2] http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
