Re: File API proposal - marrying two alternatives

On Oct 6, 2009, at 9:34 PM, Jonas Sicking wrote:

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

If data does not originate in the file system, why call it FileData?  
In any case, it feels necessary to operate in a world where content  
comes along with a media type. So I don't see the point of passing  
around a blob without any content type. Therefore, it makes sense to  
club mediaType with url and size. Only thing left is the name, which  
may be optional. In short there is little value in separating the two.

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

You are right about my API.

Do we expect "response" to hold tiny little file streams or large  
ones? I think designing for files should take into account this case.

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

Can you elaborate what is the type of data that "status" will provide?

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

Not really, my understanding reading the spec is that an  
INVALID_STATE_ERR is raised and the first request continues fine.

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

Marginally bigger, but definitely a lot clearer about the purpose.

> 2. Impossible to reuse a request object for multiple requests.

I don't think this is possible with XHR. Given that there is no  
precedent for your proposed design of using a single object for making  
multiple requests.

>
> What's the advantage of your proposal?

Concurrent access and evolves nicely with new kinds of readers and  
writers as well as with new kinds of files.

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

We can discuss this after figuring out the semantics of multiple read  
operations on a single request object.

Nikunj
http://o-micron.blogspot.com

Received on Wednesday, 7 October 2009 15:19:26 UTC