Re: File API proposal - marrying two alternatives

On Tue, Oct 6, 2009 at 9:58 PM, Garrett Smith <dhtmlkitchen@gmail.com> wrote:
> On Tue, Oct 6, 2009 at 7:32 PM, Nikunj R. Mehta <nikunj.mehta@oracle.com> wrote:
>> I figure I could rewrite Jonas' proposal to make it more palatable (at least
>> to me) and satisfy the use cases and priorities I mentioned in [1]. Here's
>> his proposal to combine with File and FileData from the current ED.
>> interface FileData {
>> readonly atribute DOMString url;
>> readonly attribute unsigned long long size;
>>   FileData slice(in long long offset, in long long length);
>> };
>> interface File : FileData {
>>   readonly attribute DOMString name;
>> readonly attribute DOMString mediaType;
>> };
>> typedef sequence<File> FileList;
>> [Constructor, Implements=EventTarget]
>> interface FileRequest {
>>  readAsBinaryString(in FileData filedata);
>>  readAsText(in FileData filedata, [Optional] in DOMString encoding);
>>  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;
>> };
>> My main issues are the following:
>>
>> "File" interface is separate from FileData and that makes little sense at
>> this time. Can't the two be merged in to "File"? (Use case 3 - all the
>> metadata)
>> "FileRequest" should be renamed as "FileReader" as Arun pointed out [2].
>> The attributes "response" and "status" from the "FileRequest" interface make
>> no sense. They are copy-pasted from XHR but their purpose is unclear. This
>> is why I said that plainly copying XHR as the template for FileReader is not
>> a good idea.
>
> Yes, I mentioned XHR for example of registering a callback for an
> asynchronous action. I did not mean to encourage copying the XHR API.
>
>> It'd be better to define the actual "FileRequest" separately from a factory
>> of "FileRequest" objects. Consider what would happen if  a
>> single "FileRequest" object is used multiple times to read as the same or
>> different data types? What happens when I abort()? (Use case 2 - concurrent
>> access & priority 2)
>
> Yes, or what if two reads are called, who gets the success callback. I
> already mentioned that, and again, in code comment below.

Same as with XHR. The second read cancels the first one.

>> What is the meaning of LOADING and DONE? Once I create the reader, it should
>> be in the LOADING state automatically. FileReader, unlike XHR, does not have
>> an explicit send step.
>>
>
> The analogous "send" step, for FileReader, is "read".
>
> var reader = getAReader();
> reader.onsuccess = handler;
>
> // Kick of "read" request.
> reader.read(aFile);
>
> Why must the reader be in LOADING state automatically?

I guess I don't feel strongly about if readystate should exist or not.
I've never fully understood what makes it so useful, but it seems
popular. HTML5 adds it to a number of objects.

I'd be fine with removing it if people don't like it.

> [...]
>
>>
>> Jonas' API:
> // Don't forget var.
>> reader = new FileReader;
>> reader.readAsBinaryString(myFile);
>
> // What happens when we start a second read?
> reader.readAsText(myFile);
> // Race is on.
>> reader.onload = handler;
>> function handler(event) {
>>  doStuffWith(event.target.response);
>> }
>>
>
> What is the order of expected outcome with multiple reads, as above?

The second read cancels the first one. So after the readAsText call
returns you'll only get events fired regarding that second load.

>> This proposal:
>> var readers = new FileReaders;
>> reader = readers.readAsBinaryString(myFile);
>> reader.onload = handler;
>> function handler(event) {
>>   doStuffWith(event.target.response);
>> }
>
> When does reading begin? Does it begin immediately, after
> "readAsBinaryString" is called? Can the implementation not return the
> file data immediately? No caching or checking the last time the file
> was modified?
>
> Getting a reader that does just one thing from a file avoids the
> problem, which is something this API does.
>
> Why not get a Reader as:-
>
>  var reader = FileReader.create(FileReader.BINARY);
>  reader.onload = handler;
>  reader.read(myFile);

I don't see this proposal changing any of the questions you've raised
above. The only thing it's changed is that once you've created a
reader you can only read data in one format. I'm not sure I see the
advantage of that API.

/ Jonas

Received on Wednesday, 7 October 2009 05:08:18 UTC