Re: Alternative File API

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

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. Your code snippets
demonstrate that it takes more busy work to use... 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.

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

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