Re: File API proposal - marrying two alternatives

On Tue, Oct 6, 2009 at 7:32 PM, Nikunj R. Mehta <nikunj.mehta@oracle.com> wrote:
> 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)

The idea was that FileData can be reused in other situations where you
have a blob of data that doesn't originate from the file system.
Similar to the blob API from gears:

http://code.google.com/apis/gears/api_summary.html

> "FileRequest" should be renamed as "FileReader" as Arun pointed out [2].

I don't really care much. However 'Request' is consistent with
XMLHttpRequest, which this API was intentionally modeled after.

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

Why do they not make sense? "response" is where the actual data is
read into. In the example for your API that appears also to be the
case, though I don't actually see the "response" property in your IDL.

"status" is used to get error information in case reading the file
failed. However we should model it closer to the "error" property on
HTMLMediaElement.

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

The same thing as with XMLHttpRequest. If you start a new request
using *the same object*, then the first request is aborted. If you
want to do two parallel requests, you create two objects. The same as
in your proposal.

The only difference between the two proposals that I can see here is
that you've created a separate factory object. I can see two
disadvantages here:
1. Bigger API since there's a separate factory object from the actual requests.
2. Impossible to reuse a request object for multiple requests.

What's the advantage of your proposal?

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

It does in my proposal. The readAsX functions act very much like the
send() function in XHR.

/ Jonas

Received on Wednesday, 7 October 2009 04:34:55 UTC