Re: Alternative File API

Hi Jonas,

I am afraid that this proposal doesn't actually improve upon the  
editor's draft in a meaningful way.

There are concepts here that are completely unrelated to file access  
such as status and readyState. There seems to be little to no benefit  
in introducing attributes just so that it is similar to XHR when your  
analysis [1] shows that only two codes are sufficient in the case of  
files! Perhaps, I am also biased (like Anne) and don't like File  
access to be matched to XHR.

Another issue I have is that as opposed to XHR, File API access does  
have the notion of incremental processing. Moreover, it has no notion  
of headers. Therefore, readyState makes no sense. Finally, the  
FileRequest interface below is a monolith, and it would require  
evolution that is not easily decentralizable because the request is  
not actually a request but a factory for causing a request. See my  
alternative proposal for how to improve on this.
Nikunj
http://o-micron.blogspot.com

[1] http://www.w3.org/mid/63df84f0908181808t19282d0bs4d227f2c04616dba@mail.gmail.com

On Aug 11, 2009, at 7:20 PM, 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,
> and the downside is that it's a significantly bigger API. Usage
> examples would be:
>
> 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);
> }
>
> I'd be interested in feedback from others, especially from people that
> so far hasn't spoken up.
>
> / Jonas
>

Received on Wednesday, 19 August 2009 19:07:04 UTC