W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: File API proposal - marrying two alternatives

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Tue, 6 Oct 2009 22:55:35 -0700
Message-ID: <c9e12660910062255t622be325yebce1199a42decf9@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: "Nikunj R. Mehta" <nikunj.mehta@oracle.com>, Web Applications Working Group WG <public-webapps@w3.org>, arun@mozilla.com
On Tue, Oct 6, 2009 at 10:07 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.

Oh come on, we all know you know you love IE :-D.

> I've never fully understood what makes it so useful, but it seems
> popular. HTML5 adds it to a number of objects.
It is used for polling. Is there is another usage for readyState
besides polling?

The callback firing would be more efficient, and result in simpler
code than polling the readyState.

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

Calling read() on the reader twice would result in an error. That
error can be avoided by create a new FileReader for each read. Same
for either of our proposals.

A bit of a side-topic, but how is a large file (2mb, etc) to be read?

Received on Wednesday, 7 October 2009 05:56:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:30 UTC