Re: Alternative File API

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

Received on Tuesday, 18 August 2009 20:11:42 UTC