On Oct 6, 2009, at 9:34 PM, Jonas Sicking wrote:
On Tue, Oct 6, 2009 at 7:32 PM, Nikunj R. Mehta <[email protected]
> 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
