Re: File API proposal - marrying two alternatives

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.


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

[...]

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

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

?

Garrett

Received on Wednesday, 7 October 2009 04:59:11 UTC