Re: Alternative File API

(posting order moved to the bottom).

On Sun, Aug 16, 2009 at 2:33 PM, Michael Nordman<michaeln@google.com> wrote:

> 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);
>>
>> 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);
>>
>> 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);
>>
>> > / Jonas
>>
>> Garrett
>>
>
>

> Currently we have File and FileData, where a File object ISA FileData
> object... completion is delivered via readXXX method completion callbacks.
> It would be easy to add progress callbacks to those readXXX methods.

Are we supposed to take your word for it, or did you want to demonstrate it?

> I think Garrets point about two different corners of the webapp issuing
> reads against a File/FileData at the same time really only becomes an issue
> when one of those two corners decides to cancelReads() on the File/FileData
> instance.

Is that a response to what I wrote: "What happens when the reader is
in process of reading?"

> Strictly speaking, I think the seperate 'Reader' class makes for a more
> correct API. The two corners above would not conflict since each would
> presumably be working with a distinct FileReader object. And the seperate
> 'Reader' with event handlers seems more javscript'y.

That is not a very compelling argument.

Your code snippets
> demonstrate that it takes more busy work to use...

I'm not sure exactly which "code snippets" you are referring to. The
"less typing" argument. Sounds like the jQuery cult.

but setting the event
> handlers has to happen somewhere.
> If we go with distinct 'Readers', maybe have the 'Data' object responsible
> for manufacturing them as there could be differences in where the 'Data'
> really resides and what it takes to retrieve it.

What is a "data" object and what are the advantages of it?

> var reader = data.createReader();
> File - represents a file in the file system
> BinaryData - represents a bag of binary bits (roughly analogous to a
> Gears.Blob)
> BinaryDataReader - an interface to read those bits
> File isa BinaryData
> XHR.ResponseBody isa BinaryData
> SQLBlob isa BinaryData
> Michael

What is that? I really have no idea what you are trying to say here. I
see a line of javascript code, followed by many lines of I don't know
what, followed by your name.

NB. Michael, Jonas, as annoying as it may be for your guys to read
this, and I really don't want to say it, please do reply inline-style.
We should be trying to communicate as effectively as possible.  The
sort of top replying over everything takes all out of context.

Inline style response shows your response juxtaposed against that to
which you are replying. It can really make point-by-point rebuttal go
a lot smoother. It also shows what you read, what you didn't, and
where communication failed.

You'll never get the hang of it if you don't try, and I think I'm not
being too pushy about it.

We all have the same goal of developing the API, right?

Thank you.

Garrett

Received on Monday, 17 August 2009 06:09:28 UTC