Re: Alternative File API

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

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

Received on Wednesday, 12 August 2009 13:35:47 UTC