Re: Alternative File API

On Sat, Aug 15, 2009 at 9:19 AM, Garrett Smith<dhtmlkitchen@gmail.com> wrote:
> On Tue, Aug 11, 2009 at 7:20 PM, Jonas Sicking<jonas@sicking.cc> wrote:
>> Here is an alternative proposal for an API for reading files:
>>
>
> [snip proposal]
>
>>
>> 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:
>>
>
> The advantage to having the callback as an event is that it lets
> multiple callbacks be attached easily to the read.
>
> The File can be found in the DOM as:-
>
> var files = input.files,
>    file =  files && files[0];
>
> That file might be gotten from two separate unrelated parts of the
> code. Each could a callback to that file and issue different getXXX
> commands to it, creating a race condition whereby one callback could
> get called where it was expecting the payload to have text and another
> callback to get called where it was expecting a payload of binary
> text.
>
> Instead, a separate reader can be obtained to read the file and that
> reader can have the callback.
>
>> Current draft:
>> myFile.getAsBinaryString(handler);
>> function handler(data, error) {
>>  doStuffWith(data);
>> }
>>
>> Above API:
>
> // Is it "FileRequest" or "FileReader"?
>> reader = new FileReader;
>
> // The following two statements are backwards.
>> reader.readAsBinaryString(myFile);
>> reader.onload = handler;
>> function handler(event) {
>>  doStuffWith(event.target.response);
>> }
>>
>
> What happens when the reader is in process of reading?
> var reader = new FileReader;
> reader.onload = handler;
> reader.readAsBinaryString(myFile);
> reader.readAsText(myFile);

Indeed, we need to define what happens here. I don't think it makes a
big difference either way.

> The callback would have to know in advance what type of read happened.
> So you'd want to have a different reader for each type of read. For
> example:-
>
> var bReader = new FileReader;
> bReader.onload = handler;
> bReader.readAsBinaryString(myFile);
> var tReader = new FileReader;
> tReader.readAsText(myFile);

That would be the way to use the API I proposed if you want to do
multiple parallel reads, yes.

> As you can see, the read /type/ is exclusive to the reader. "tReader"
> is only reading "text" and "bReader" is only reading binary. Each
> reader reads only one type. So doesn't a Factory seem more appropriate
> than a bunch of constructors?
>
> var bReader = FileReader.create(FileReader.BINARY); // (the "etc" part).
> bReader.onload = handler;
> bReader.read(myFile);

I see, now I understand your proposal better. Thanks.

>> / Jonas
>
> Garrett

/ Jonas

Received on Sunday, 16 August 2009 22:32:16 UTC